Fakt des Tages

Eine kleine Kalender-Webseite: Sie zeigt den Fakt des heutigen Tages und einen Kalender, über den sich die Fakten anderer Tage aufrufen lassen. Statische Seite, gehostet auf GitHub Pages, komplett auf Deutsch.

Nach dem ersten Deploy erreichbar unter https://abduelhamit.github.io/Fakt-des-Tages/.

Einen Fakt hinzufügen

Alle Fakten stehen in einer Datei: src/lib/facts.yaml. Sie lässt sich direkt im GitHub-Webeditor bearbeiten — eine lokale Entwicklungsumgebung ist dafür nicht nötig.

2026-08-22: Ein kurzer Fakt passt einzeilig.

2026-08-23: |
  Ein längerer Fakt mit **fettem** und *kursivem* Text sowie einem
  [Link](https://example.com).

  Ein zweiter Absatz ist ebenfalls möglich:

  - erster Punkt
  - zweiter Punkt

Regeln:

• Der Schlüssel ist immer ein exaktes Datum im Format JJJJ-MM-TT. Ein Eintrag für 2026-03-15 gilt nur für diesen einen Tag, nicht für jeden 15. März.
• Der Wert ist CommonMark. Links, Hervorhebungen, Zitate, Listen und Zwischenüberschriften mit ## werden gestaltet, andere Überschriften und Tabellen nicht.
• Mehrzeilige Fakten brauchen einen |-Block, dessen Zeilen alle gleich weit eingerückt sind. Das ist die häufigste Fehlerquelle beim Bearbeiten im Browser.
• Tage ohne Eintrag sind im Kalender sichtbar, aber nicht anklickbar. Lücken sind also in Ordnung. Einzige Ausnahme ist der heutige Tag — er bleibt anklickbar, damit man immer zu ihm zurückfindet.
• Die Pfeile über dem Kalender führen nur zu Monaten, in denen es Einträge gibt — und immer bis zum heutigen Tag zurück. Stehen alle Fakten im selben Monat wie heute, sind deshalb beide Pfeile ausgegraut.
• Die Pfeile neben dem Datum springen zum nächsten bzw. vorherigen Eintrag und überspringen dabei die Tage ohne Fakt. Der Kalender wandert mit, notfalls in einen anderen Monat.
• Jeder Tag mit einem Fakt hat eine eigene Adresse, etwa https://abduelhamit.github.io/Fakt-des-Tages/2026-08-21. So lässt sich ein einzelner Fakt verlinken.
• Ein Fakt verweist auf einen anderen mit dem bloßen Datum als Ziel, etwa [Fakt vom 24.08.](2026-08-24). Gibt es für das Datum keinen Eintrag, schlägt der Build fehl.

Bilder

Bilder liegen in static/fakten/ und werden relativ eingebunden:

2026-03-06: |
  Ein Fakt mit Bild.

  ![Was auf dem Bild zu sehen ist](fakten/2026-03-06-1.avif)

• Der Text in den eckigen Klammern ist die Bildbeschreibung für Menschen, die die Seite vorgelesen bekommen. Bitte beschreiben, was zu sehen ist, statt „Bild“ zu schreiben.
• Neue Bilder brauchen einen lokalen Klon mit Git LFS. Die Dateien liegen dort und nicht direkt im Repository. Am Text eines Fakts ändert das nichts — der bleibt im Webeditor bearbeitbar.
• Fehlt eine Bilddatei oder stimmt der Pfad nicht, schlägt der Build fehl. Auch hier geht also nichts Kaputtes online.

Bitte beachten:

• Ein fehlerhafter Eintrag lässt den Build fehlschlagen. Die Seite wird dann gar nicht erst veröffentlicht — die bisherige Fassung bleibt online, und die Fehlermeldung in GitHub Actions nennt den betroffenen Schlüssel. Kaputte Inhalte gehen also nie live.
• Jedes Datum darf nur einmal vorkommen. Ein doppelter Schlüssel ist ein Fehler.
• Niemals eine %YAML 1.1-Zeile ergänzen. Die Datumsschlüssel würden dadurch zu Datumsobjekten, und es würde stillschweigend kein einziger Fakt mehr gefunden.

Nach einem Push auf main baut GitHub Actions die Seite neu und veröffentlicht sie. Dabei entsteht für jeden Fakt eine eigene, fertige Seite. Zum Pflegen der Inhalte genügt trotzdem der Webeditor — der Build läuft ja automatisch.

Entwicklung

Voraussetzungen: Node ≥ 26 und pnpm (die Version ist in package.json unter packageManager festgelegt). Mit einer älteren Node-Version bricht pnpm install mit Expected version: >=26 ab — nvm use --lts hilft.

pnpm install
pnpm dev        # http://localhost:5173/Fakt-des-Tages

Die Seite läuft auch lokal unter dem Unterpfad /Fakt-des-Tages, weil sie auf GitHub Pages in einem Projektverzeichnis liegt. Wer http://localhost:5173/ aufruft, wird automatisch dorthin weitergeleitet.

Befehl	Zweck
pnpm dev	Entwicklungsserver
pnpm build	Produktions-Build nach build/
pnpm preview	Den gebauten Stand lokal ausliefern
pnpm check	Typprüfung, auch in .svelte-Dateien
pnpm lint	Prettier- und ESLint-Prüfung
pnpm format	Formatierung schreiben
pnpm test	Alle Tests einmalig ausführen

Es gibt zwei Testebenen: schnelle Node-Tests (*.spec.ts) und Playwright-Tests im echten Browser (*.e2e.ts). pnpm test führt beide aus, pnpm test:unit --run nur die schnellen.

pnpm vitest run                         # nur die Node-Tests
pnpm test:e2e                           # nur die Browser-Tests

Für die Browser-Tests muss einmalig pnpm exec playwright install chromium ausgeführt werden. Die Node-Tests prüfen unter anderem, ob src/lib/facts.yaml fehlerfrei ist — sie laufen bei jedem Deploy und stoppen ihn bei einem Tippfehler.

Deployment

Ein Push auf main startet .github/workflows/deploy.yml: check → lint → build, anschließend die Veröffentlichung auf GitHub Pages. Pages wird beim ersten erfolgreichen Durchlauf automatisch aktiviert.

Technisches

Aufbau, Konventionen und die Fallstricke des Projekts sind in CLAUDE.md dokumentiert — unter anderem, warum es keine svelte.config.js gibt und warum jeder Fakt schon beim Build eine eigene Seite bekommt.