6273f20484
Die Karte zeigte Kacheln und stand am richtigen Ort, zeichnete aber weder in der Trail-Uebersicht noch auf der Detailseite eine Linie. Das Hoehenprofil aus denselben Versionsdaten wurde dagegen gerendert. Ursache: MapLibre 6 liegt als drei Dateien vor (Haupteinstiegspunkt, shared, worker) und laedt den Worker zur Laufzeit ueber import.meta.url aus dem eigenen Verzeichnis nach. Vites Dependency-Optimierung buendelt jedoch nur den Haupteinstiegspunkt nach node_modules/.vite/deps — daneben liegt keine maplibre-gl-worker.mjs. Der Worker startet dadurch zwar und ist verbunden, sein Import laeuft aber ins Leere: Er antwortet auf keine Nachricht mehr. GeoJSON-Quellen bleiben deshalb dauerhaft im Ladezustand (isSourceLoaded false, keine Source-Features, _updatePromise loest nie auf), und es gibt nichts zu zeichnen. Rasterkacheln brauchen keinen Worker, deshalb erschien die Karte trotzdem und der Fehler sah nach fehlenden Daten aus. setWorkerUrl mit einem ?url-Import zeigt auf die echte Datei und umgeht das, ohne in Vites Optimierung einzugreifen. Ein optimizeDeps.exclude waere der naheliegendere Weg gewesen, bricht hier aber die Modulaufloesung von SvelteKit. Verifiziert: Linie erscheint in Uebersicht und Detailseite; die Daten waren durchgehend intakt (LineString, 225 Koordinaten). svelte-check ohne Fehler, alle 19 Tests bestehen, npm run build erfolgreich, und die Worker-Datei liegt als Asset im Produktionsbuild und wird vom Client-Bundle referenziert. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| scripts | ||
| src | ||
| static | ||
| .env.example | ||
| .npmrc | ||
| components.json | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| svelte.config.js | ||
| tsconfig.json | ||
| vite.config.ts | ||
stammtisch-hersbruck.de — Frontend
SvelteKit-5-Anwendung (Svelte 5 Runes, Tailwind 4) für Zeitnahme und Verwaltung.
Einrichten
.env aus der Vorlage anlegen und ausfüllen — .env.example beschreibt jede
Variable:
cp .env.example .env
npm ci
npm run dev
Die App läuft dann auf http://stammtisch-hersbruck.de.localhost:31337
Befehle
| Befehl | Zweck |
|---|---|
npm run dev |
Development-Server (Port 31337, strict) |
npm run build |
Produktions-Build |
npm run preview |
Produktions-Build lokal ansehen |
npm run check |
Typprüfung (svelte-check) |
npm run check:watch |
Typprüfung im Watch-Modus |
npm run generate-pocketbase-types |
src/lib/types.d.ts aus dem PocketBase-Schema erzeugen |
Welche PocketBase-Instanz?
PUBLIC_PB_URL in .env entscheidet, wohin das Frontend spricht:
| Wert | Instanz |
|---|---|
https://api.stammtisch-hersbruck.de |
produktiv (Default) |
http://127.0.0.1:8090 |
lokales Backend aus ../backend |
Die Variable wird von SvelteKit zur Buildzeit eingesetzt
($env/static/public). Ein Wechsel der Instanz erfordert deshalb einen
Neustart des Dev-Servers bzw. einen neuen Build — ein bloßer Neustart des
Containers genügt nicht.
Es ist die einzige Variable in .env; ein Token wird nicht mehr gebraucht.
Deployment
Gebaut wird mit adapter-node; der Startbefehl ist node build.
adapter-auto funktioniert hier nicht — es erkennt Coolify nicht, meldet
„Could not detect a supported production environment" und erzeugt gar kein
build/, woraufhin node build sofort scheitert.
Zwei Dinge müssen in der Deployment-Umgebung stimmen:
PUBLIC_PB_URL muss als Environment-Variable gesetzt sein. Sie wird zur
Buildzeit eingesetzt; fehlt sie, bricht schon der Build ab:
"PUBLIC_PB_URL" is not exported by "virtual:env/static/public"
Die .env aus dem Arbeitsverzeichnis steht auf dem Build-Server nicht zur
Verfügung — sie ist gitignored.
Node ≥ 22.12. Das engines-Feld in package.json schreibt die Anforderung
von vite und @sveltejs/vite-plugin-svelte fest. Zusammen mit
engine-strict=true aus der .npmrc bricht npm ci bei einer älteren
Version ab (EBADENGINE) — was bei Node 22.11 aus einem
NIXPACKS_NODE_VERSION=22 bereits passiert ist.
Typen
Das maßgebliche Schema liegt als Migration in ../backend/pb_migrations/.
Daraus entstehen auch die TypeScript-Typen:
npm run generate-pocketbase-types
Das Script liest das Collections-Array aus der Migration
(scripts/schema-to-json.mjs) und erzeugt daraus src/lib/types.d.ts. Es
braucht keine laufende Instanz, keinen Token und keinen Netzwerkzugriff —
Schema und Typen kommen aus derselben versionierten Quelle und können deshalb
nicht auseinanderlaufen.
Nach jeder Schema-Änderung in ../backend/pb_migrations/ einmal ausführen und
die aktualisierte types.d.ts mitcommitten.
Die System-Collections (
_superusers,_mfas, …) stehen bewusst nicht in der Migration und fehlen deshalb in den Typen. Die Anwendung verwendet sie nicht.