# 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. ## 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.