- Rename eslint-config → core-eslint, typescript-config → core-typescript in all docs (package map, AGENTS.md, overview.md, dependency-flow.md, etc.) - Document the five-tag model (app, feature, core, core-composition, tooling) — refinement of ADR-006's three-tag mention - Document core-trpc's core-composition tag (transitively reaches features through core-api's AppRouter type) - Note Turborepo boundaries as a second enforcement layer alongside ESLint - Add ADR-010 explaining the two-layer enforcement decision and five-tag refinement Files updated: - docs/architecture/overview.md: package map, enforcement layers, five-tag section - docs/architecture/dependency-flow.md: boundary rules, enforcement strategy - docs/architecture/vertical-feature-spec.md: package names, five-tag model - AGENTS.md: package map, boundary rules, commands - CLAUDE.md: tooling package names, quick-start command - packages/core-eslint/AGENTS.md: tag clarification - packages/core-typescript/AGENTS.md: tag clarification - packages/core-api/AGENTS.md: core-composition tag - packages/core-cms/AGENTS.md: core-composition tag - packages/core-trpc/AGENTS.md: core-composition tag + rationale - docs/decisions/adr-010-turbo-boundaries.md: new ADR Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
124 lines
6.5 KiB
Markdown
124 lines
6.5 KiB
Markdown
# ADR-010: Turborepo boundaries alongside ESLint enforcement
|
|
|
|
**Status:** Accepted
|
|
**Date:** 2026-05-04
|
|
**Supersedes:** ADR-006 (partial refinement; not a contradiction)
|
|
|
|
## Context
|
|
|
|
ADR-006 established the vertical-feature monorepo with three tags (`app`, `feature`, `core`). ESLint with `eslint-plugin-boundaries` was introduced to enforce direct-import boundaries at lint time, catching violations like:
|
|
|
|
- Feature package importing from another feature
|
|
- Core package importing from a feature
|
|
- Deep imports past public `exports` map boundaries
|
|
|
|
However, ESLint has two intrinsic limitations:
|
|
|
|
1. **No transitive enforcement** — If `core-trpc` imports `core-api` (which imports feature routers), ESLint sees only the direct edge `core-trpc` → `core-api`. The transitive reach into features is invisible. A package can declare `@repo/feature-x` as a dependency without ever importing it directly.
|
|
|
|
2. **No declared-dep enforcement** — A `package.json` dependency that doesn't match an actual import goes undetected. Conversely, a `package.json` dependency might be missing but the transitive graph still allows the code to work.
|
|
|
|
The result: two types of dependency drift escape lint-time checking:
|
|
|
|
- A composition package's transitive reach into features (real problem: `core-trpc` → `core-api` → `feature-blog-routers`)
|
|
- Incorrect or missing `package.json` declarations
|
|
|
|
## Decision
|
|
|
|
Add Turborepo's `boundaries` feature as a second enforcement layer running at **build-graph time** (before build), parallel to ESLint's lint-time checks.
|
|
|
|
### Five-tag model (refined from ADR-006)
|
|
|
|
ADR-006 mentioned three tags. This ADR refines the model to five, distinguishing composition packages explicitly:
|
|
|
|
- **app** — `apps/web-next`, `apps/web-tanstack`, `apps/cms`, `apps/storybook`
|
|
- **core** — `packages/core-shared`, `core-ui` (pure foundation, no transitive feature reach)
|
|
- **core-composition** — `packages/core-api`, `core-cms`, `core-trpc` (composition or transitively reach features)
|
|
- **feature** — `packages/auth`, `blog`, `media`, `marketing-pages`, `navigation`
|
|
- **tooling** — `packages/core-eslint`, `core-typescript`
|
|
|
|
Why `core-trpc` is `core-composition`:
|
|
- `core-trpc` imports `@repo/core-api` (the tRPC app router)
|
|
- `core-api` imports feature routers from `@repo/<feature>/api`
|
|
- Therefore, `core-trpc` transitively depends on features through the `AppRouter` type
|
|
- This violates ADR-006's "core → NOT feature" rule if we treat `core-trpc` as plain `core`
|
|
- Solution: tag `core-trpc` as `core-composition` to make the transitive reach explicit and allowed
|
|
|
|
### Implementation
|
|
|
|
1. **Root `turbo.json`** declares boundary rules as a `boundaries.tags` config:
|
|
```json
|
|
{
|
|
"boundaries": {
|
|
"tags": {
|
|
"app": { "dependencies": { "allow": ["app", "core", "core-composition", "feature", "tooling"] } },
|
|
"core-composition": { "dependencies": { "allow": ["core", "core-composition", "feature", "tooling"] } },
|
|
"core": { "dependencies": { "allow": ["core", "core-composition", "tooling"] } },
|
|
"feature": { "dependencies": { "allow": ["core", "tooling"] } },
|
|
"tooling": { "dependencies": { "allow": ["tooling"] } }
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
2. **Per-package `turbo.json`** declares the package's tag:
|
|
```json
|
|
// packages/blog/turbo.json
|
|
{ "extends": ["../../../turbo.json"], "tasks": { /* ... */ } }
|
|
// package.json
|
|
{ "turbo": { "tasks": { "build": { /* ... */ } }, "tags": ["feature"] } }
|
|
```
|
|
|
|
3. **CLI validation** — `pnpm turbo boundaries` runs the check in <1 second without building anything
|
|
|
|
### Two layers, not one
|
|
|
|
Both ESLint and Turborepo enforce the same five-tag rules, but for different reasons:
|
|
|
|
| Layer | Runs | Sees | Exempts via |
|
|
|---|---|---|---|
|
|
| ESLint `eslint-plugin-boundaries` | lint-time | Direct imports per file | `// @boundaries-ignore` comments |
|
|
| Turborepo `boundaries` | build-graph time | Entire workspace dependency graph including transitives | None (graph-based, not per-import) |
|
|
|
|
**Why both?**
|
|
- **ESLint** provides fine-grained control (file-level exemptions) and immediate feedback during development
|
|
- **Turborepo** catches transitive issues (e.g., feature reach through composition packages) and missing declarations
|
|
|
|
**Enforcement** — CI runs both: `pnpm lint` (includes ESLint) and `pnpm turbo boundaries`.
|
|
|
|
## Consequences
|
|
|
|
1. **Two independent checks** — developers get immediate ESLint feedback and a final Turbo gate in CI
|
|
2. **Both must stay in sync** — when adding a new tag rule, update both:
|
|
- `packages/core-eslint/base.js` (ESLint `eslint-plugin-boundaries` config)
|
|
- Root `turbo.json` (`boundaries.tags` config)
|
|
- Per-package `package.json` `turbo.tags` declaration
|
|
3. **Stricter than before** — Turborepo sees transitives; some patterns that pass ESLint may fail Turbo:
|
|
- Example: `packages/cms` might try to use `@repo/<dep>` indirectly (not importing, but depending)
|
|
- Solution: declare the dependency explicitly or restructure the import
|
|
4. **The five-tag model is a refinement, not a contradiction** — ADR-006 mentioned three tags; this ADR adds `core-composition` and `tooling` explicitly and moves them into the boundary enforcement
|
|
5. **`core-trpc`'s new tag** — previously thought of as `core`, now explicitly `core-composition` to match its transitive reach; any code assuming `core-trpc` is `core` must be updated
|
|
|
|
## Alternatives considered
|
|
|
|
1. **ESLint only** — Simple, immediate feedback. Downside: misses transitive issues; no build-graph validation.
|
|
2. **Turborepo only** — Catches everything eventually, but slower feedback cycle; less granular exemptions.
|
|
3. **Both in series** — ESLint first (fast), Turbo second (thorough). Chosen.
|
|
4. **Custom graph validator** — Over-engineered; Turborepo's built-in feature is stable and designed for this.
|
|
|
|
## Related
|
|
|
|
- **ADR-006:** Vertical feature packages (the original three-tag model)
|
|
- **ADR-009:** Integrations folder naming
|
|
- **`packages/core-eslint/base.js`** — ESLint configuration
|
|
- **Root `turbo.json`** — Turborepo configuration with boundaries rules
|
|
- **`docs/architecture/overview.md`** — Package map and five-tag summary
|
|
- **`docs/architecture/dependency-flow.md`** — Enforcement layers and rules
|
|
- **`AGENTS.md`** — Per-package boundary documentation
|
|
|
|
## Timeline
|
|
|
|
- **2026-05-04** — Turborepo boundaries added alongside existing ESLint enforcement
|
|
- **CI integration** — `pnpm turbo boundaries` added to lint stage
|
|
- **Documentation** — Updated AGENTS.md, overview.md, dependency-flow.md, vertical-feature-spec.md
|