Found while deriving the real vitest layout for the published-skills sweep (ui#7094). Out of that PR's file surface (skills/objectui/** only), so filed rather than fixed.
The defect
Root package.json:
"test:unit": "vitest run --project unit",
"test:integration": "vitest run --project ui",
vitest.config.mts declares exactly three named projects — unit, dom, dom-heavy — plus apps/console's own config brought in by absolute path. There is no project named ui.
Measured at origin/main@2c3cd1b:
$ pnpm exec vitest run --project ui
Startup Error
Error: No projects matched the filter "ui".
EXIT=1
pnpm test:unit works (--project unit resolves).
Severity
Low but real, and it fails in the good direction: passWithNoTests is !cliHasTestFilters(process.argv), and vitest rejects the unmatched project filter at startup rather than reporting a green empty run — so this is a script nobody can run, not silent coverage loss. Worth fixing because it is a documented root script and because the near-miss (a filter that matched nothing and exited 0) is the exact failure objectui#3288 hardened against.
Suggested fix
Decide what "integration" means now that the split is unit / dom / dom-heavy and point the script at it — most likely --project dom --project dom-heavy, or --project dom-heavy alone if the intent was the registry-rendering tier. Whichever is chosen, a pin in scripts/__tests__/ asserting every --project name in root package.json appears in vitest.config.mts's project list would keep the two from drifting again; that pairing is the generalizable half of this card.
Related: ui#7094 (the sweep that found it).
Generated by Claude Code
Found while deriving the real vitest layout for the published-skills sweep (ui#7094). Out of that PR's file surface (
skills/objectui/**only), so filed rather than fixed.The defect
Root
package.json:vitest.config.mtsdeclares exactly three named projects —unit,dom,dom-heavy— plusapps/console's own config brought in by absolute path. There is no project namedui.Measured at
origin/main@2c3cd1b:pnpm test:unitworks (--project unitresolves).Severity
Low but real, and it fails in the good direction:
passWithNoTestsis!cliHasTestFilters(process.argv), and vitest rejects the unmatched project filter at startup rather than reporting a green empty run — so this is a script nobody can run, not silent coverage loss. Worth fixing because it is a documented root script and because the near-miss (a filter that matched nothing and exited 0) is the exact failure objectui#3288 hardened against.Suggested fix
Decide what "integration" means now that the split is
unit/dom/dom-heavyand point the script at it — most likely--project dom --project dom-heavy, or--project dom-heavyalone if the intent was the registry-rendering tier. Whichever is chosen, a pin inscripts/__tests__/asserting every--projectname in rootpackage.jsonappears invitest.config.mts's project list would keep the two from drifting again; that pairing is the generalizable half of this card.Related: ui#7094 (the sweep that found it).
Generated by Claude Code