tooling: investigate replacing Biome with ESLint and Prettier

[QuentinRoy]

Context

Biome 2.5.2 introduced an editor regression in this repository: the VS Code language server scans the project and then stops responding, so Biome is not offered as a formatter for TypeScript/TSX even though CLI formatting still works. Pinning Biome to 2.5.1 restores editor formatting.

This is another instance where the repository's formatter, linter, editor integration, custom Biome plugin, and separate dependency-cruiser boundary check form a tooling stack with overlapping responsibilities and different failure modes.

ADR 0010 chose dependency-cruiser over eslint-plugin-boundaries specifically to avoid adding ESLint alongside Biome. If Biome is replaced with ESLint, that trade-off changes: ESLint plugins may be able to enforce both lint rules and the architectural dependency rules, while Prettier provides formatting through a separate, widely supported editor integration.

Relevant upstream report: biomejs/biome-vscode#745

Goal

Decide whether replacing Biome with ESLint and Prettier would improve editor reliability and tooling maintainability without weakening linting, formatting, or the architectural boundaries established by ADR 0010.

If the investigation supports migration, produce an implementation plan that preserves current behavior and provides a controlled transition.

Possible direction

• Inventory every enabled Biome rule, domain, formatter option, assist action, and custom plugin rule.
• Map that inventory to ESLint, typescript-eslint, React/Next.js plugins, import-related plugins, and Prettier; record gaps and semantic differences rather than assuming name-level parity.
• Prototype ESLint flat config and a standalone Prettier configuration.
• Evaluate eslint-plugin-boundaries for layer direction and vertical isolation, plus an import plugin's cycle detection for the current no-circular rule.
• Verify that TypeScript path aliases, test/story exemptions, shared-domain restrictions, and design-system restrictions behave exactly like the current dependency-cruiser configuration.
• Keep ESLint and Prettier as separate checks; use eslint-config-prettier to disable conflicting lint rules rather than running Prettier as an ESLint rule.
• Compare local/CI performance and VS Code reliability with the existing Biome 2.5.1 + dependency-cruiser baseline.
• If migration is selected, update or supersede ADR 0010's tooling decision and stage the rollout so CI never loses enforcement.

Acceptance criteria

• Every currently enabled Biome lint rule and custom plugin rule has an explicit ESLint equivalent, an intentionally accepted behavior change, or a documented blocker.
• Prettier can reproduce an agreed formatting baseline for all currently formatted file types, with any unavoidable repository-wide formatting diff quantified before migration.
• A boundary-enforcement spike proves whether ESLint plugins can detect all four current dependency-cruiser constraints: cycles, shared-domain upward imports, design-system upward imports, and cross-vertical imports.
• Existing test and Storybook exemptions are covered without weakening production-code boundaries.
• The proposed editor setup supports TypeScript and TSX formatting on save and ESLint fixes without competing formatters or code-action loops.
• CLI and CI commands provide separate deterministic lint, format-check, type-check, and architecture-check signals.
• Runtime, CI duration, dependency count, and maintenance trade-offs are compared against the current toolchain.
• The investigation concludes with one of: migrate fully, migrate while retaining dependency-cruiser, or retain Biome with the reasons documented.
• Any accepted migration includes documentation/ADR updates, rollout steps, and a rollback path.

Non-goals

• Changing the architectural layering rules established by ADR 0010.
• Removing dependency-cruiser before equivalent enforcement has been demonstrated.
• Combining the migration with unrelated source refactors or stylistic changes.
• Treating the Biome 2.5.2 downgrade as proof by itself that ESLint and Prettier are the correct long-term choice.