Architektur-Regeln im Frontend prüfen (dependency-cruiser) #123

New issue

Open

opened 2026-10-20 12:23:12 +00:00 by claude · 0 comments

claude commented

2026-10-20 12:23:12 +00:00

Collaborator

Gegenstück zu #120 (Backend, ArchUnit) für die Frontends. Besprochen am 20.10.2026, Stand main 8ac1b58.

Stand heute

portal und content haben ESLint, aber nur die Standardregeln für React-Hooks und React-Refresh. Eine Architekturregel ist nicht dabei.
homepage und packages/shared haben gar kein ESLint.
Die CI fährt lint nicht. Ein Lint-Fehler blockiert nichts.
Die einzige Architekturprüfung im Frontend ist der Sweep in metrics.py: Komponenten, die selbst Daten laden (COMPONENT_FETCH_ALLOW). Er läuft nur bei /project-review, also nach dem Merge. Das ist dasselbe Muster wie im Backend vor #120.

Vorschlag

dependency-cruiser. Ein Werkzeug für alle Workspaces einschliesslich Astro, eine Konfiguration in der Wurzel, als CI-Schritt neben „Schema-Drift“. Den Altbestand hält eine Baseline-Datei fest (--ignore-known); anschlagen tut es nur bei neuen Verstössen.

Kandidaten sind die Grenzen, die es heute schon gibt, nur ungeprüft:

packages/shared importiert nie aus einer App, und keine App importiert aus einer anderen.
Nur lib/ spricht mit dem Backend. fetch und lib/api kommen in components/ nicht vor. Das entspricht dem bestehenden Sweep.
Vertragstypen kommen aus @sffs/api-types, nicht von Hand geschrieben (Regel in CLAUDE.md).
Keine Import-Zyklen.

Zur Wahl standen auch eslint-plugin-boundaries bzw. no-restricted-imports (rot direkt im Editor, aber homepage und shared haben kein ESLint) und ArchUnitTS (wenig verbreitet).

Für den Plan

Die Schichtung innerhalb einer App (pages → hooks → lib) erst festlegen, wenn die Struktur der Frontends so angesehen ist wie am 20.10. die des Backends. Keine Regeln auf Verdacht.
Ob lint zusätzlich in die CI kommt, ist eine eigene Frage.
Sobald dependency-cruiser Regel 2 prüft, liest die Review-Rubrik dessen Ergebnis, statt denselben Sweep ein zweites Mal zu fahren. Das ist eine Rubrik-Änderung, also eine neue Version.

Abnahme

Die CI schlägt an, wenn packages/shared aus portal/src importiert. Der Gegentest mit einem absichtlich eingebauten Verstoss ist rot.
Die CI schlägt an, wenn eine Komponente in components/ lib/api importiert und dafür kein Eintrag in der Baseline steht.
Der Altbestand blockiert den Build nicht.
Die Regeln stehen in CLAUDE.md unter Frontend.

Gegenstück zu #120 (Backend, ArchUnit) für die Frontends. Besprochen am 20.10.2026, Stand `main` 8ac1b58. ## Stand heute - **portal** und **content** haben ESLint, aber nur die Standardregeln für React-Hooks und React-Refresh. Eine Architekturregel ist nicht dabei. - **homepage** und **packages/shared** haben gar kein ESLint. - **Die CI fährt `lint` nicht.** Ein Lint-Fehler blockiert nichts. - Die einzige Architekturprüfung im Frontend ist der Sweep in `metrics.py`: Komponenten, die selbst Daten laden (`COMPONENT_FETCH_ALLOW`). Er läuft nur bei `/project-review`, also nach dem Merge. Das ist dasselbe Muster wie im Backend vor #120. ## Vorschlag **dependency-cruiser.** Ein Werkzeug für alle Workspaces einschliesslich Astro, eine Konfiguration in der Wurzel, als CI-Schritt neben „Schema-Drift“. Den Altbestand hält eine Baseline-Datei fest (`--ignore-known`); anschlagen tut es nur bei neuen Verstössen. Kandidaten sind die Grenzen, die es heute schon gibt, nur ungeprüft: 1. `packages/shared` importiert nie aus einer App, und keine App importiert aus einer anderen. 2. Nur `lib/` spricht mit dem Backend. `fetch` und `lib/api` kommen in `components/` nicht vor. Das entspricht dem bestehenden Sweep. 3. Vertragstypen kommen aus `@sffs/api-types`, nicht von Hand geschrieben (Regel in CLAUDE.md). 4. Keine Import-Zyklen. Zur Wahl standen auch `eslint-plugin-boundaries` bzw. `no-restricted-imports` (rot direkt im Editor, aber homepage und shared haben kein ESLint) und ArchUnitTS (wenig verbreitet). ## Für den Plan - **Die Schichtung innerhalb einer App** (pages → hooks → lib) erst festlegen, wenn die Struktur der Frontends so angesehen ist wie am 20.10. die des Backends. Keine Regeln auf Verdacht. - Ob `lint` zusätzlich in die CI kommt, ist eine eigene Frage. - Sobald dependency-cruiser Regel 2 prüft, liest die Review-Rubrik dessen Ergebnis, statt denselben Sweep ein zweites Mal zu fahren. Das ist eine Rubrik-Änderung, also eine neue Version. ## Abnahme - Die CI schlägt an, wenn `packages/shared` aus `portal/src` importiert. Der Gegentest mit einem absichtlich eingebauten Verstoss ist rot. - Die CI schlägt an, wenn eine Komponente in `components/` `lib/api` importiert und dafür kein Eintrag in der Baseline steht. - Der Altbestand blockiert den Build nicht. - Die Regeln stehen in CLAUDE.md unter Frontend.