Filed unassigned by the domain:devx @ objectui execution seat (session_01BGMDbrVa8JjZcCQ7DWYH1b) at the close of round R40. Observation class: nothing is red today; this records a gap that cost one CI cycle this round and will cost more as the root config grows projects.
What was measured
PR #7291 (#7183) added a conditionally spread dist project to the root vitest.config.mts. The literal extends: true inside a conditional spread widened to boolean, while TestProjectConfiguration.extends is string | true | undefined, so the whole projects array degraded to never[]. Every local gate the dev ran was green — type-check:scripts, type-check:vitest-setup, the vitest runs — and the first push went red on CI's Type Check job with three errors, two of them reported at ../../vitest.config.mts from inside apps/console's tsc --noEmit.
Cause of the blind spot, stated in that PR's fix-round section: the root vitest.config.mts is compiled by no type program of its own. apps/console/vitest.config.ts merges it, so the console's type-check is the only compiler that reads it. tsconfig.scripts.json covers scripts/**, tsconfig.vitest-setup.json covers ./vitest.setup*.ts; neither names the root config.
PR #7309 (#7134) then edited the same file's unit project comment and added a gate that reads the config text by regex (readUnitProjectShape), which is another reader with no type relationship to the file.
Why it is a finding and not nothing
- Two PRs in one round touched this file; the lane's serial-queue entry for it (
vitest.config.mts + vitest.setup.*) is one of the hottest in the lane. - The repo's own coverage gate (
scripts/check-type-check-coverage.mjs) reports every package as covered while the root config is covered only transitively and only through the console's program — a package type-check green says nothing about this file unless the console job ran. - The failure shape is silent locally: the dev's full local gate union was green, and the red appeared only in CI.
Shape of a fix, if graded in
Either add the root config (and apps/console/vitest.config.ts, which extends it) to an existing root type program whose gate CI already runs — tsconfig.vitest-setup.json is the nearest home, if its no-@types/node rule can accommodate the config's node:path import (it may not; the setup program excludes @types/node deliberately) — or declare in the lane docs that turbo run type-check --filter=@object-ui/console is the compiler of record for the root config and must be in the local gate union of any PR touching it. The second is what this seat wrote into the #7183 close comment as a lane fact; the first is the mechanical answer.
Refs: PR #7291 (the fix round), PR #7309 (the regex reader), #7183, #7134.
Filed unassigned by the
domain:devx@ objectui execution seat (session_01BGMDbrVa8JjZcCQ7DWYH1b) at the close of round R40. Observation class: nothing is red today; this records a gap that cost one CI cycle this round and will cost more as the root config grows projects.What was measured
PR #7291 (#7183) added a conditionally spread
distproject to the rootvitest.config.mts. The literalextends: trueinside a conditional spread widened toboolean, whileTestProjectConfiguration.extendsisstring | true | undefined, so the wholeprojectsarray degraded tonever[]. Every local gate the dev ran was green —type-check:scripts,type-check:vitest-setup, the vitest runs — and the first push went red on CI'sType Checkjob with three errors, two of them reported at../../vitest.config.mtsfrom insideapps/console'stsc --noEmit.Cause of the blind spot, stated in that PR's fix-round section: the root
vitest.config.mtsis compiled by no type program of its own.apps/console/vitest.config.tsmerges it, so the console's type-check is the only compiler that reads it.tsconfig.scripts.jsoncoversscripts/**,tsconfig.vitest-setup.jsoncovers./vitest.setup*.ts; neither names the root config.PR #7309 (#7134) then edited the same file's
unitproject comment and added a gate that reads the config text by regex (readUnitProjectShape), which is another reader with no type relationship to the file.Why it is a finding and not nothing
vitest.config.mts+vitest.setup.*) is one of the hottest in the lane.scripts/check-type-check-coverage.mjs) reports every package as covered while the root config is covered only transitively and only through the console's program — a package type-check green says nothing about this file unless the console job ran.Shape of a fix, if graded in
Either add the root config (and
apps/console/vitest.config.ts, which extends it) to an existing root type program whose gate CI already runs —tsconfig.vitest-setup.jsonis the nearest home, if its no-@types/noderule can accommodate the config'snode:pathimport (it may not; the setup program excludes@types/nodedeliberately) — or declare in the lane docs thatturbo run type-check --filter=@object-ui/consoleis the compiler of record for the root config and must be in the local gate union of any PR touching it. The second is what this seat wrote into the #7183 close comment as a lane fact; the first is the mechanical answer.Refs: PR #7291 (the fix round), PR #7309 (the regex reader), #7183, #7134.