Repository navigation
pnpm --filter <pkg> test -- --run <paths> 静默忽略路径过滤:新加的测试文件根本没跑,而输出看起来正常 #3288
Description
Activity
在 #3314(PR #3369)的验证里又撞到同一族,并且拿到一条比标题更强的证据 —— 不是「带路径时路径被忽略」,而是不带任何路径的包级
test本身就跑错了包。复现
在
objectui-issue-3314worktree(baseorigin/main@68b6a28)里:pnpm --workspace-concurrency=2 --filter @object-ui/core test # RUN … /packages/core Test Files 20 passed (20) Tests 184 passed (184) pnpm --workspace-concurrency=2 --filter @object-ui/react test # RUN … /packages/react Test Files 20 passed (20) Tests 184 passed (184)两个完全不同的包,逐字相同的 20 / 184。header 里还煞有介事地打印
RUN v4.1.10 …/packages/core与…/packages/react。用
vitest list把收集到的文件打出来,才看到跑的是什么:cd packages/react && npx vitest list --filesOnly [@object-ui/console] ../../apps/console/src/LocalizationFetchProvider.test.tsx [@object-ui/console] ../../apps/console/src/__tests__/preview-samples-spec-valid.test.ts …(20 行,全部 [@object-ui/console])20 个文件全部来自
apps/console,没有一个来自packages/react。 我新加的
packages/react/src/hooks/__tests__/actionPredicate.parity.test.tsx根本没被收集
(grep actionPredicate.parity→ 无命中)。机制
根
vitest.config.mts的projects里,unit/dom/dom-heavy三个项目的
include写的是仓根相对 glob(packages/**/*.test.ts),而apps/console那个
project 是用 绝对路径path.resolve(__dirname, './apps/console/vitest.config.ts')
挂进来的。从packages/<pkg>/启动时,前三个项目的 glob 相对当前包目录解析 →
匹配 0 个文件;只有绝对路径挂载的 console project 仍然完整收集。于是
passWithNoTests: true让整轮安静地全绿。所以这条不只是「路径过滤失效」:任何
pnpm --filter <pkg> test的绿都不代表该包被测过,
而 AGENTS.md 与各处派发提示都把「只跑受影响的包」写成推荐做法。正确跑法(本轮实际用的)
从仓库根:
npx vitest run --maxWorkers=2 packages/core packages/react npx vitest run --project unit packages/core/src/actions/__tests__/ActionEngine.visibility.test.ts npx vitest list --filesOnly <paths> # 先确认「新测试真的被收集了」CI 不受影响:
.github/workflows/ci.yml明确注释了要跑根 vitest project
(pnpm test --shard=…/4)而不是turbo run test,所以覆盖在 CI 里是全的 ——
被坑的只有本地/agent 的包级调用。对建议方向的一点补充
原 issue 的 A(匹配不到就非零退出)在这个形态下不够 —— 这里不带路径,也就没有
「传了路径却匹配不到」可检。更贴的是:包级test脚本要么在启动时校验
「本包至少收集到 1 个属于本包的文件,否则报错」,要么干脆把包级脚本改成从仓根调用
并注入本包路径(原 C)。passWithNoTests: true在这里正是把信号吃掉的那一环。
Generated by Claude Code
认领:objectui 分片 PM 并行批第 33 单(与 #3378 同文件面同 dispatch,分支
claude/issue-3378-pkg-test-false-green,PR 同时 Fixes 两单;详见 #3378 认领评论)
会话:session_01GTRjn8xBqp75dk7kFupVRt
方向按 issue 倾向取 A + B:传了路径但零匹配 / collect 到 0 个本包文件 → 响亮失败;AGENTS.md 写明从仓根跑的正确方式。C(路径改写转发)若实现代价可控由 dev 一并评估,但不作为验收必需。
Generated by Claude Code
在 objectui#3275(PR #3285)的验证过程中撞到,按 Prime Directive #10 单独记录。
现象
用包级过滤加路径跑测试时:
路径过滤被静默忽略。加了新测试文件之前和之后,输出都是同一个
Test Files 20 passed (20) / Tests 183 passed (183)—— 也就是说新写的测试一个都没有执行,而输出看起来完全正常:全绿、有数字、没有任何警告。vitest 按仓库根解析 pattern,包级
--filter转发过去的相对路径匹配不到任何东西,于是退回跑该包的默认集合。正确的跑法
从仓库根:
换过去之后立刻抓到一个真实失败(
AppPreview.test.tsx里getByText命中了重复元素)—— 那个失败在错误的调用方式下被完全隐藏了。为什么值得单独修
这是本仓反复出现的那一类缺陷的元层版本:一个「看起来跑了」的验证等于没验证。
危害具体在:
与 objectui#3240(两套 vitest 配置对同一文件给出不同结论)是同一族:门禁在特定调用方式下给出的答案不作数。
建议方向
至少三条,不预设结论:
test脚本能检出"传了路径但一个都没匹配上",就 exit 非零。最小改动,直接消除"安静跑错东西"。test脚本正确转发路径(把相对路径改写成仓根相对)。最彻底,但要确认不会破坏现有调用方式。倾向 A + B(让错误方式响亮失败,同时把正确方式写下来);C 更彻底但需要评估 turbo / vitest 两层的转发行为。
发现路径:objectui#3275 / PR #3285 的验证。