frontend/ci: Build-Hinweis in die App-Quelle, env-gesteuert; Prod-Build ohne
Der Latest-Build-Hinweis wandert vom Workflow-sed in die App (app.js, mountBuildBadge), damit ihn auch der Dev-Server zeigt — ein Post-Build-sed erreicht den Dev-Server nicht. Logik umgekehrt: Hinweis ist der Normalfall, nur die produktive Installation schaltet ihn ab. Drei Zustaende ueber Vite-Env VITE_BUILD_BADGE (Auswertung in app.js): - Dev-Server (import.meta.env.DEV) -> 🔧 "Vorschau/lokaler Entwicklungsstand" - Default `npm run build` (Env ungesetzt) -> 🚧 "latest build"; der Pages- Deploy nutzt den Default und traegt den Hinweis dadurch automatisch (die sed-Injektion entfaellt). - `npm run build:prod` (Vite-Modus prod, .env.prod: VITE_BUILD_BADGE=none) -> KEIN Badge; esbuild eliminiert den Zweig als toten Code. Verifiziert zur Laufzeit (Dev + `vite preview` auf beiden Builds): 🔧 im Dev, 🚧 im Default-Build, gar nichts im Prod-Build (Titel sauber "Werkbaum"). 34 Vitest-Tests gruen, Workflow-YAML/Shell gueltig. Doku: D16 fortgeschrieben (quellbasiert/env statt sed, Begruendung); README (de/en) mit Prod-Build-Anleitung inkl. LICENSE-/Versions-Caveats; frontend/ CLAUDE.md; .claude/launch.json bekommt einen frontend-dist-Preview (vite preview, Port 8138) zum Verifizieren gebauter Dateien. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.8
parent
b7bf9182ea
commit
0f27bab905
+23
-12
@@ -135,18 +135,29 @@ zählt der flache CI-Klon nur einen Commit. `1.0` bleibt die Version beim lokale
|
||||
Links**: „Werkbaum" → Repo-Startseite, die Versionsnummer (`<a class="ver">`) →
|
||||
exakt der deployte Commit (`…/commit/<sha>`, im Build via `git rev-parse HEAD`).
|
||||
|
||||
**Latest-Build-Hinweis:** Der Pages-Deploy ist der jeweils frischeste
|
||||
Entwicklungsstand und kann Fehler enthalten; die *eigentliche* (stabile) Instanz
|
||||
läuft woanders. Damit nur diese Veröffentlichung als „latest build" markiert ist,
|
||||
injiziert der Workflow — nach demselben Muster wie Version/LICENSE, also **nur auf
|
||||
der Site-Kopie** — hinter dem Titel (`</h1>`, im Bundle eindeutiger Anker) ein
|
||||
kleines Symbol mit Tooltip (`<span class="build-badge">🚧</span>`, zweisprachiger
|
||||
`title`). Die Quelle bleibt unberührt: ein schlichter `npm run build` (z. B. für
|
||||
die stabile Instanz) erzeugt die Datei **ohne** Hinweis. Bewusst nicht als
|
||||
i18n-UI-Text im `I18N`-Objekt, weil es kein Produkt-Feature ist, sondern
|
||||
Deploy-Metainformation genau dieser Pipeline (D14: die Quelle nicht um
|
||||
Deploy-Spezifika erweitern). Umgesetzt mit literalen UTF-8-Zeichen im
|
||||
`sed`-Replacement (kein `#`/`&`, sonst kollidiert der Delimiter).
|
||||
**Build-Hinweis (Vorschau / „latest build"):** Nicht-produktive Builds tragen
|
||||
hinter dem Titel ein kleines Symbol samt Tooltip, damit klar ist, dass es nicht
|
||||
die *eigentliche* (stabile) Instanz ist. Drei Zustände, gesteuert per Vite-Env
|
||||
`VITE_BUILD_BADGE` (Auswertung in `app.js`, `mountBuildBadge`):
|
||||
|
||||
- **Dev-Server** (`import.meta.env.DEV`) → 🔧 „Vorschau – lokaler Entwicklungsstand".
|
||||
- **Default-Build** `npm run build` (Env ungesetzt) → 🚧 „latest build …". Der
|
||||
GitHub-Pages-Deploy nutzt genau diesen Default und trägt den Hinweis dadurch
|
||||
automatisch — **keine** `sed`-Injektion mehr nötig.
|
||||
- **Produktions-Build** `npm run build:prod` (Vite-Modus `prod`, `frontend/.env.prod`
|
||||
setzt `VITE_BUILD_BADGE=none`) → **kein** Badge; esbuild eliminiert den Zweig
|
||||
als toten Code, das Symbol steht dann nicht einmal mehr im Ausgabe-Quelltext.
|
||||
|
||||
Damit trägt einzig die echte produktive Installation keinen Hinweis. **Warum in
|
||||
die App-Quelle statt per Workflow-`sed` (frühere Lösung):** Nur so sieht der
|
||||
Dev-Server den Hinweis ebenfalls — ein Post-Build-`sed` erreicht den Dev-Server
|
||||
nicht, der die Quelle direkt ausliefert. Die Umkehrung „Hinweis ist der
|
||||
Normalfall, Prod schaltet ab" passt zudem zur Anforderung (nur Prod bleibt sauber)
|
||||
und macht den Default sicher: wer den Prod-Schritt vergisst, veröffentlicht einen
|
||||
sichtbar als Entwicklungsstand markierten Build, nicht versehentlich einen als
|
||||
stabil wirkenden. Bewusst **kein** i18n-UI-Text im `I18N`-Objekt (kein
|
||||
Produkt-Feature, sondern Build-Metainformation; D14) — der `title` ist knapp
|
||||
zweisprachig (DE · EN).
|
||||
|
||||
(Nummerierung: D15 war bereits für den kompakten Modus vergeben, daher D16.)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user