3.5 KiB
Entscheidungen
Stand der Quellenprüfung: 21. Oktober 2026. Verwendet wurden offizielle Dokumentationen und die npm-Registry für konkrete Paket-Metadaten.
D-001: SvelteKit 3 und Node-Unterstützung
Die Anwendung verwendet SvelteKit 3, Svelte 5, TypeScript und Vite 8. Das
Projekt wurde gemäß aktueller Empfehlung mit npx sv create angelegt. Die
Kit-Konfiguration liegt bei SvelteKit 3 in vite.config.ts, nicht in einer
svelte.config.js.
Die lokale Mindestversion ist Node 22.17. Das Cloudron-Image nutzt Node 24 LTS. Der vorhandene lokale Lauf wurde mit Node 22.23.1 geplant.
Quellen:
- https://svelte.dev/docs/kit/creating-a-project
- https://svelte.dev/docs/kit/migrating-to-sveltekit-3
- https://svelte.dev/docs/cli/sv-create
- npm-Metadaten für
@sveltejs/kit3.1.0 am 21.10.2026
D-002: Offizieller Node-Adapter
@sveltejs/adapter-node erzeugt den Produktionsserver in build/. Gebaut wird
mit npm run build, gestartet mit node build. HOST und PORT konfigurieren
den Server. Der Adapter behandelt SIGTERM/SIGINT und kontrolliertes Herunter-
fahren; ein eigener Server ist für Etappe 1 nicht erforderlich.
Quelle: https://svelte.dev/docs/kit/adapter-node
D-003: SQLite mit better-sqlite3
better-sqlite3 13.x wird als gekapselter synchroner Treiber verwendet. Das
Paket ist MIT-lizenziert und verlangt Node 22 oder neuer. Gegenüber
node:sqlite wird damit in Etappe 1 keine API verwendet, die in der offiziellen
Node-24-Dokumentation noch als Release Candidate gekennzeichnet ist. Die
Datenbankgrenze bleibt in src/lib/server gekapselt.
Migrationen sind eigene nummerierte SQL-Dateien und laufen transaktional. WAL wird in Etappe 1 nicht aktiviert; für die kleine Redaktion ist das Rollback-Journal zunächst ausreichend und vereinfacht die frühe Betriebsprüfung.
Quellen:
- https://nodejs.org/docs/latest-v24.x/api/sqlite.html
- https://www.sqlite.org/lang_transaction.html
- npm-Metadaten für
better-sqlite313.0.3 am 21.10.2026
D-004: Cloudron-Paket
Das Paket nutzt manifestVersion: 2, internen HTTP-Port 3000 und /healthz.
localstorage.sqlite.paths nennt /app/data/sendewerk.sqlite, damit Cloudron
eine konsistente Sicherung der aktiven SQLite-Datei erstellen kann. Das
Startskript stellt Verzeichnisse und Besitzrechte her, migriert als Benutzer
cloudron und ersetzt sich zuletzt per exec durch den Node-Prozess.
Das Image ist auf die am 21.10.2026 offiziell dokumentierte datierte Node-24-
Basis samt Digest gepinnt. Außer /app/data, /run und /tmp wird das
Laufzeitdateisystem als read-only behandelt.
Quellen:
- https://docs.cloudron.io/packaging/
- https://docs.cloudron.io/packaging/manifest/
- https://docs.cloudron.io/packaging/addons/#localstorage
- https://docs.cloudron.io/packaging/cheat-sheet/
D-005: Theme ohne serverseitiges Nutzerkonto
Etappe 1 speichert light, dark oder system in localStorage. Ein kurzes
Inline-Skript in app.html setzt das resultierende Theme vor dem ersten Paint
auf dem Wurzelelement. Dies vermeidet einen falschen Theme-Blitz und benötigt
vor Etappe 2 weder Cookie noch Konto. Die Einstellung bleibt bei Neuladen im
gleichen Browser erhalten.
D-006: Etappe-1-Vorschauen statt Attrappen
Vorschauseiten lesen echte persistente SQLite-Seed-Daten, bieten aber keine funktionslosen Speichern- oder Live-Schaltflächen. Ein sichtbarer Hinweis grenzt Gestaltungsvorschauen von den späteren Fachfunktionen ab. Damit wird keine noch nicht implementierte Funktion als fertig dargestellt.