chore(lint): ESLint v9 Flat-Config-Adoption in 7 Workspaces nachziehen + CI-Filter aufheben #409

New issue

Closed

opened 2026-05-25 22:53:39 +02:00 by pm-bot · 0 comments

pm-bot commented

2026-05-25 22:53:39 +02:00

Collaborator

Symptom

Lokales pnpm lint in packages/auth failt mit:

ESLint couldn't find an eslint.config.(js|mjs|cjs) file. From ESLint v9.0.0, the default configuration file is now eslint.config.js.

Beim Anlegen von #404-Fix entdeckt — bestätigt auch auf origin/main reproduzierbar, also kein Regression-Bug, sondern bestehende Lücke.

Scope (größer als ein Package)

10 Workspaces haben ein "lint": "eslint src" Script, nur 3 haben tatsächlich eine eslint.config.js:

Workspace	hat `eslint.config.js`?	lint-fähig?
`apps/api`	✅	✅
`apps/web`	✅	✅
`packages/shared-types`	✅	✅
`apps/mobile`	❌	❌
`packages/auth`	❌	❌
`packages/api-client`	❌	❌
`packages/feature-lists`	❌	❌
`packages/feature-shopping-list`	❌	❌
`packages/feature-tracking`	❌	❌
`packages/ui`	❌	❌

CI-Drone-Lint-Step deckt es derzeit mit

pnpm exec turbo run lint --filter=@mrrmlab/api --filter=@mrrmlab/shared-types

zu — die kaputten 7 werden gar nicht ausgeführt, fail-silent.

PO-Einschätzung (PM-Hut)

Prio: medium. Kein User-facing Symptom, kein Sicherheitsproblem, aber sichtbare DX-Reibung sobald jemand lokal in den kaputten Packages lintet.
Aufwand: ~2–4h. 7× ein 3-Zeilen-Config-File + ggf. Lint-Fixes für Bestandsfehler die jetzt erstmals auflaufen.
Wann: NACH v0.4.6. Hotfix-Cut sauber halten, nicht mit Chore-Drift mischen. Frühestens v0.4.7 oder eigene Chore-Iteration.
Label-Vorschlag: type/chore, area/infra, prio/medium.
Risiko: gering falls die Bestandsfehler sich in Grenzen halten. Falls ein Package Hunderte Warnings produziert: dann splitten (ein Issue pro Package) statt im Big-Bang.

Architekt-Einschätzung (Architekt-Hut, informell)

Konvention existiert bereits. packages/config/eslint/{base,node,react}.js ist die zentrale Shared-Config — nicht neu erfinden, nur konsumieren.

Migrations-Pattern (trivial pro Package):

// packages/<name>/eslint.config.js
export { default } from '@mrrmlab/config/eslint/base';
// oder ../node bzw. ../react je nach Runtime

Welche Variante pro Package:
- base (pure TS): packages/auth, packages/api-client, packages/shared-types (✅ schon so)
- react: packages/ui, packages/feature-lists, packages/feature-shopping-list, packages/feature-tracking, apps/mobile
- node: apps/api (✅ schon so)
Kritischer Schritt der nicht vergessen werden darf: Nach Adoption den CI-Filter aufheben in .drone.yml:
```
- pnpm exec turbo run lint --filter=@mrrmlab/api --filter=@mrrmlab/shared-types
+ pnpm exec turbo run lint
```
Ohne diesen Schritt ist die Migration kosmetisch — CI bleibt blind für die neu konfigurierten Packages.
Empfehlung Bestandsfehler: nicht whitelisten/eslint-disable-streuen. Lieber pro Package fixen oder, wenn akut nicht machbar, das eine Package vorerst aus dem CI-Filter herausnehmen (transparente Schuld) statt Disable-Kommentare einschleusen (versteckte Schuld). Lange Lebensdauer von Disable-Kommentaren ist erfahrungsgemäß ein Tech-Debt-Anker.
Tragweite: kein Architektur-Entscheid mit Konsequenzen für Runtime/Persistenz/API — daher informelle Einschätzung statt arch-question-Flow.

Akzeptanz

Alle 7 fehlenden Workspaces haben eine eslint.config.js die aus @mrrmlab/config/eslint/* re-exportiert
pnpm lint läuft in jedem Workspace ohne Setup-Fehler durch (Lint-Findings dürfen zunächst auflaufen — siehe Sub-Tasks)
CI-Lint-Step in .drone.yml läuft ohne --filter und ist grün
Etwaige Bestandsfehler entweder gefixt oder bewusst durch CI-Exclude statt durch eslint-disable behandelt

Empfehlung Reihenfolge

Configs in alle 7 Packages legen (atomar, ein PR)
Lokal pnpm -r lint laufen lassen → Findings inventarisieren
Pro Package entscheiden: fixen vs. CI-Exclude (eigener PR, ggf. Sub-Issues)
CI-Filter entfernen — sobald alle inkludierten Packages clean sind

## Symptom Lokales `pnpm lint` in `packages/auth` failt mit: > ESLint couldn't find an eslint.config.(js|mjs|cjs) file. From ESLint v9.0.0, the default configuration file is now eslint.config.js. Beim Anlegen von #404-Fix entdeckt — bestätigt auch auf `origin/main` reproduzierbar, also kein Regression-Bug, sondern bestehende Lücke. ## Scope (größer als ein Package) 10 Workspaces haben ein `"lint": "eslint src"` Script, nur **3** haben tatsächlich eine `eslint.config.js`: | Workspace | hat `eslint.config.js`? | lint-fähig? | |---|---|---| | `apps/api` | ✅ | ✅ | | `apps/web` | ✅ | ✅ | | `packages/shared-types` | ✅ | ✅ | | `apps/mobile` | ❌ | ❌ | | `packages/auth` | ❌ | ❌ | | `packages/api-client` | ❌ | ❌ | | `packages/feature-lists` | ❌ | ❌ | | `packages/feature-shopping-list` | ❌ | ❌ | | `packages/feature-tracking` | ❌ | ❌ | | `packages/ui` | ❌ | ❌ | CI-Drone-Lint-Step deckt es derzeit mit ``` pnpm exec turbo run lint --filter=@mrrmlab/api --filter=@mrrmlab/shared-types ``` zu — die kaputten 7 werden gar nicht ausgeführt, fail-silent. ## PO-Einschätzung (PM-Hut) - **Prio: medium.** Kein User-facing Symptom, kein Sicherheitsproblem, aber sichtbare DX-Reibung sobald jemand lokal in den kaputten Packages lintet. - **Aufwand: ~2–4h.** 7× ein 3-Zeilen-Config-File + ggf. Lint-Fixes für Bestandsfehler die jetzt erstmals auflaufen. - **Wann: NACH v0.4.6.** Hotfix-Cut sauber halten, nicht mit Chore-Drift mischen. Frühestens v0.4.7 oder eigene Chore-Iteration. - **Label-Vorschlag:** `type/chore`, `area/infra`, `prio/medium`. - **Risiko: gering** falls die Bestandsfehler sich in Grenzen halten. Falls ein Package Hunderte Warnings produziert: dann splitten (ein Issue pro Package) statt im Big-Bang. ## Architekt-Einschätzung (Architekt-Hut, informell) - **Konvention existiert bereits.** `packages/config/eslint/{base,node,react}.js` ist die zentrale Shared-Config — nicht neu erfinden, nur konsumieren. - **Migrations-Pattern (trivial pro Package):** ```js // packages/<name>/eslint.config.js export { default } from '@mrrmlab/config/eslint/base'; // oder ../node bzw. ../react je nach Runtime ``` - **Welche Variante pro Package:** - `base` (pure TS): `packages/auth`, `packages/api-client`, `packages/shared-types` (✅ schon so) - `react`: `packages/ui`, `packages/feature-lists`, `packages/feature-shopping-list`, `packages/feature-tracking`, `apps/mobile` - `node`: `apps/api` (✅ schon so) - **Kritischer Schritt der nicht vergessen werden darf:** Nach Adoption den **CI-Filter aufheben** in `.drone.yml`: ```diff - pnpm exec turbo run lint --filter=@mrrmlab/api --filter=@mrrmlab/shared-types + pnpm exec turbo run lint ``` Ohne diesen Schritt ist die Migration kosmetisch — CI bleibt blind für die neu konfigurierten Packages. - **Empfehlung Bestandsfehler:** **nicht** whitelisten/`eslint-disable`-streuen. Lieber pro Package fixen oder, wenn akut nicht machbar, das eine Package vorerst aus dem CI-Filter herausnehmen (transparente Schuld) statt Disable-Kommentare einschleusen (versteckte Schuld). Lange Lebensdauer von Disable-Kommentaren ist erfahrungsgemäß ein Tech-Debt-Anker. - **Tragweite:** kein Architektur-Entscheid mit Konsequenzen für Runtime/Persistenz/API — daher informelle Einschätzung statt `arch-question`-Flow. ## Akzeptanz - [ ] Alle 7 fehlenden Workspaces haben eine `eslint.config.js` die aus `@mrrmlab/config/eslint/*` re-exportiert - [ ] `pnpm lint` läuft in jedem Workspace ohne Setup-Fehler durch (Lint-Findings dürfen zunächst auflaufen — siehe Sub-Tasks) - [ ] CI-Lint-Step in `.drone.yml` läuft ohne `--filter` und ist grün - [ ] Etwaige Bestandsfehler entweder gefixt oder bewusst durch CI-Exclude statt durch `eslint-disable` behandelt ## Empfehlung Reihenfolge 1. Configs in alle 7 Packages legen (atomar, ein PR) 2. Lokal `pnpm -r lint` laufen lassen → Findings inventarisieren 3. Pro Package entscheiden: fixen vs. CI-Exclude (eigener PR, ggf. Sub-Issues) 4. CI-Filter entfernen — sobald alle inkludierten Packages clean sind