f316058367
Das Coolify-Deployment scheiterte an zwei Stellen:
1. npm ci brach mit EBADENGINE ab. Coolify baute mit Node 22.11.0, vite und
@sveltejs/vite-plugin-svelte verlangen aber >=22.12; engine-strict=true
aus der .npmrc macht daraus einen Abbruch statt einer Warnung. Das
engines-Feld schreibt die Anforderung jetzt im Repo fest, statt sie einer
Einstellung in der Coolify-UI zu überlassen.
2. Selbst nach erfolgreichem npm ci wäre der Start gescheitert: adapter-auto
erkennt Coolify nicht ("Could not detect a supported production
environment") und erzeugt gar kein build/ — der Startbefehl "node build"
findet dann nichts. Jetzt adapter-node, adapter-auto entfällt.
Verifiziert in einer frischen Kopie ohne node_modules, mit derselben Kette
wie im Deployment: npm ci läuft durch, npm run build erzeugt build/index.js,
node build antwortet auf / und /login mit HTTP 200.
Dabei fiel ein dritter Punkt auf, der keine Code-Änderung braucht, aber im
Deployment gesetzt sein muss: PUBLIC_PB_URL wird zur Buildzeit eingesetzt.
Fehlt sie, bricht der Build mit "PUBLIC_PB_URL is not exported by
virtual:env/static/public" ab. Steht jetzt in frontend/README.md und CLAUDE.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
84 lines
3 KiB
Markdown
84 lines
3 KiB
Markdown
# 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.
|