guard: turbo `type-check` 的手维护 inputs 名单已两次因"包程序越出包目录"失真 —— 评估从 tsconfig include 派生或加钉扎测试

[yinlianghui]

Tripped over while implementing #3476 (PR #3513). Filed unassigned; not fixed there because turbo.json was outside that task's file fence.

The gap

apps/console's type-check script compiles a program that deliberately spans the repo root:

• ../../scripts/vite-crypto-stub.ts, ../../scripts/vite-maplibre-worker.ts (already there)
• ../../vitest.config.mts (added by PR ci(console): 把 vitest.config.ts 纳入 tsc program,并把根 vitest 配置算进 turbo 的 cache key #3513, because apps/console/vitest.config.ts imports it and a composite project must list every file in its program)

turbo.json's type-check task hashes:

"inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/scripts/vite-*.ts"]

$TURBO_DEFAULT$ only covers files inside the package directory, and globalDependencies is unset. That second entry exists precisely to close this hole for the scripts/vite-*.ts half — nothing covers vitest.config.mts.

Measured

On PR #3513's branch: run type-check green so it caches, then plant a real type error in the root vitest.config.mts and re-run only the console filter.

$ npx turbo run type-check --filter @object-ui/console --concurrency=2
@object-ui/console:type-check: cache hit, replaying logs 4214aa6ab3df0f18
 Tasks:    35 successful, 35 total
  Time:    315ms  FULL TURBO

Turbo replayed a green while the program contained:

../../vitest.config.mts(114,5): error TS2769: No overload matches this call.
    Type 'string' is not assignable to type 'number'.

A cold run on the same tree exits 1. So the verdict depends on cache state, not on the code.

Not local-only: .github/workflows/ci.yml persists .turbo/cache via actions/cache, so a warm CI cache can carry the stale green across runs.

Suggested fix

Symmetric with the entry already there — one line:

-      "inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/scripts/vite-*.ts"]
+      "inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/scripts/vite-*.ts", "$TURBO_ROOT$/vitest.config.mts"]

Worth considering alongside it: this list is a thing to keep honest by hand, and it has now been wrong twice for the same structural reason (a package's tsc program reaching outside its own directory). Whether that deserves a guard — something that derives the extra inputs from the tsconfig include, or pins the pair — is a maintainer call, not part of the one-liner.

Ordering

Only bites once PR #3513 merges (before that, vitest.config.mts is in no gated program at all). The scripts/vite-*.ts half is already handled, so there is nothing broken on main today.

Blocked-by: #3513

---

Generated by Claude Code

[yinlianghui]

PM 裁定(re-scope) — 会话 session_01GTRjn8xBqp75dk7kFupVRt:

原文的一行修复($TURBO_ROOT$/vitest.config.mts 进 type-check inputs)已裁定并入 PR #3513(#3476 的单,PM 显式放宽文件面)—— 明知落地一个"缓存态决定判决"的半武装门禁,正是本仓已付过三次学费的"看着像执行、实际不是"failure class,不留两合并之间的 stale-green 窗口。

本单从"缺一行"改承载 C 方向(已改标题):手维护的 inputs 名单因同一结构性原因(包的 tsc 程序越出包目录)已错过两次,评估①从 tsconfig include 派生额外 inputs,或②加一条钉扎测试(断言 turbo inputs ⊇ 各包 tsconfig 越出目录的文件)。两条路线成本/收益不同,需要单独实测的 PR,不是一行事。

Blocked-by 从 #3513 解除(一行并入后本单不再依赖其合并时序,是纯预防性设计单)。另:本单与 #3515 均是在 list_issues 配额中断下未完成查重就立的(dev 已披露),PM 复核查重待配额恢复 —— 若撞已有单,以先到者为准合并。

---

Generated by Claude Code

[claude]

Triage: finding (held, not queued) — because the concrete hole is being closed by an in-flight PR and what remains is explicitly an evaluation.

Stale-premise check, and it changed the answer. The body says the fix was left out "because turbo.json was outside that task's file fence". That is no longer true: draft PR #3513 (claude/issue-3476-console-vitest-tsc, opened 02:00:30Z — one minute before this issue) now carries two files, apps/console/tsconfig.node.json and turbo.json, and its own body states the second commit adds $TURBO_ROOT$/vitest.config.mts to the type-check task's inputs — the one-line symmetric fix this issue's "Suggested fix" section asks for. The PR took option A of the two it offered. So the measured cache hole (turbo replaying FULL TURBO green over a real TS2769 in the root config, and CI's persisted .turbo/cache carrying it) is resolved by #3513, not by this issue.

What survives is the durability question, and it is observation-class: the inputs list is hand-maintained and has now drifted twice for the same structural reason (a package's tsc program reaching outside its package directory). The ask — derive the list from tsconfig include, or add a pinning test — has no decided shape and no user hitting it once #3513 lands. That is the finding definition, and grading happens in the findings-triage round, not at filing.

Promotion condition, so this is not a state nobody can exit: promote to pm:queue when either (a) #3513 lands and someone picks a concrete guard shape (derivation vs pin test), or (b) a third drift instance appears — at which point the counter-argument for a generic guard is measured rather than anticipated.

Dedup (three repos, open issues + PRs): no duplicate. cloud#1133 (pm:queue) is the same family one repo over — turbo test inputs covering only the package's own src/test while three repo-level assertion tests read from outside it — and is worth reading before designing a guard here; whoever moves first should say so on the other. #3476 (finding) is this issue's parent finding (the console vitest config type-checked by nothing) and is what #3513 fixes. objectstack#5278 is a different mechanism (DEBT ledger counts), not this.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code