0002 — Feature-Flag-Zustände über Fixture-Konfigurationen absichern

Status: angenommen · Milestone: M2

Kontext

Feature-Flags erzeugen Codepfade, die im Alltag nie ausgeführt werden. Ein Flag, das niemand einschaltet, verrottet unbemerkt — und fällt erst in dem Kundenprojekt auf, das es zuerst braucht. Der Starter braucht deshalb einen Mechanismus, der beide Zustände jedes Flags regelmäßig baut.

Entscheidung

Es gibt zwei Fixture-Konfigurationen unter tests/fixtures/configs/:

• minimal — alle optionalen Funktionen aus
• full — alle optionalen Funktionen an

Beide werden über astro build --config … gebaut und sind Teil von pnpm verify. Jede Fixture bringt eine eigene, sehr kurze astro.config.ts mit, die dieselbe Fabrik defineAstroConfig() nutzt wie das Projekt selbst und lediglich ein eigenes Ausgabeverzeichnis setzt.

Eine dritte Fixture, invalid, enthält eine typkorrekte, aber fachlich verbotene Kombination. Ein Integrationstest startet damit einen echten Build und prüft, dass er mit einem Fehlercode abbricht und die Ursache benennt.

Begründung

astro build --config ist eine dokumentierte Astro-Funktion und braucht keine Sonderbehandlung. Der ursprüngliche Plan sah vor, den Pfad zur Projektkonfiguration über eine Umgebungsvariable in der Integration aufzulösen. Das hätte bedeutet, zur Laufzeit eine TypeScript-Datei dynamisch zu importieren — ohne Bundler unzuverlässig und abhängig davon, wie die eingesetzte Node-Version mit TypeScript umgeht. Der --config-Weg erreicht dasselbe Ziel ohne diese Fragilität.

Die Regel „Flag an, Paket fehlt" lässt sich auf diesem Weg nicht als Build prüfen, denn @astrojs/vue ist im Starter bewusst nicht installiert. Sie wird stattdessen im Unit-Test mit einem eingeschleusten Resolver abgedeckt.

Verworfene Alternativen

Konfigurationsdateien in der CI kopieren. Nicht lokal reproduzierbar und die Quelle des Builds wäre nicht mehr an der Datei ablesbar.

Fixtures statisch in astro.config.ts importieren und per Umgebungsvariable auswählen. Hätte Testfixtures in die Produktivkonfiguration jedes Kundenprojekts gezogen.

Eine CI-Matrix mit einem Job je Fixture. Doppelte Installation ohne Erkenntnisgewinn; die Builds dauern jeweils unter einer Sekunde und passen in denselben Job.

Konsequenzen

• Ein neues Feature-Flag ist erst vollständig, wenn beide Zustände in den Fixtures vorkommen.
• Die Fixture-Ausgabeverzeichnisse dist-fixture-* sind versionsignoriert.
• Ab M3 dienen dieselben Fixtures als Grundlage der End-to-End-Tests.