9f075f0f6c
Eine Stage laesst sich nicht wiederholen. Zwei Dinge durften deshalb nicht so bleiben, wie sie waren. Erstens die Uhr. Zeiten entstehen auf den Geraeten an der Strecke — nur so laesst sich im Funkloch ueberhaupt stoppen. Damit steckte aber der Versatz zweier Telefonuhren in jeder Dauer, bei der einer am Start und ein anderer im Ziel drueckt. Jedes Geraet gleicht sich jetzt gegen den Server ab (Cristian: t0 merken, Serverzeit holen, t1 merken, Versatz = T + RTT/2 - t1), sieben Proben, Median ueber die schnellste Haelfte. Der Versatz liegt im localStorage und wird auf jeden Zeitstempel gerechnet. Dafuer eine eigene Route /api/clock in den Hooks: Der Date-Header jeder gewoehnlichen Antwort hat nach RFC 9110 Sekundenaufloesung, allein daraus folgte ein Fehler von bis zu einer halben Sekunde — auf einer Stage der Unterschied zwischen Platz eins und Platz drei. Zweitens das Netz. Scheitert die Uebertragung eines Starts oder Stopps an einem Funkloch, wandert er in einen Ausgang im localStorage statt in einen Fehler und geht raus, sobald wieder Empfang da ist. Die massgebliche Zeit ist die des Druckens, nicht die der Uebertragung. Ein Stopp kann dabei auf einen Start warten, der selbst noch aussteht. Unterschieden wird streng zwischen Funkloch und Absage: Eine abgelehnte Anfrage — fehlende Rechte, ungueltige Daten — wird gemeldet und nicht aufgefangen, sonst sammelte der Ausgang stumm Eintraege, die auch beim naechsten Versuch scheitern. Die Leiste der laufenden Zeiten zeigt nicht uebertragene Zeiten ganz oben und erscheint dafuer auch dann, wenn gerade nichts laeuft. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P32KoesVtABd6xWsqMKzhr |
||
|---|---|---|
| .. | ||
| 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.