This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
pnpm --filter <pkg> test -- --run <paths> 静默忽略路径过滤:新加的测试文件根本没跑,而输出看起来正常 #3288
Description
在 objectui#3275(PR #3285)的验证过程中撞到,按 Prime Directive #10 单独记录。
现象
用包级过滤加路径跑测试时:
pnpm --filter @object-ui/app-shell test -- --run <paths>
路径过滤被静默忽略。加了新测试文件之前和之后,输出都是同一个 Test Files 20 passed (20) / Tests 183 passed (183) —— 也就是说新写的测试一个都没有执行,而输出看起来完全正常:全绿、有数字、没有任何警告。
vitest 按仓库根解析 pattern,包级 --filter 转发过去的相对路径匹配不到任何东西,于是退回跑该包的默认集合。
正确的跑法
从仓库根:
pnpm exec vitest run packages/app-shell/src/views/... --maxWorkers=2
换过去之后立刻抓到一个真实失败(AppPreview.test.tsx 里 getByText 命中了重复元素)—— 那个失败在错误的调用方式下被完全隐藏了。
为什么值得单独修
这是本仓反复出现的那一类缺陷的元层版本:一个「看起来跑了」的验证等于没验证。
危害具体在:
- agent 与开发者会据此报告"测试通过",而实际上新增的覆盖一次都没执行 —— 本轮就发生了一次,靠换命令才发现;
- 它不报错、不警告,只是安静地跑了别的东西,所以没有任何自然的发现路径;
- AGENTS.md 建议本地只跑受影响的包,而包级过滤正是最自然的写法 —— 也就是说推荐路径与陷阱重合。
与 objectui#3240(两套 vitest 配置对同一文件给出不同结论)是同一族:门禁在特定调用方式下给出的答案不作数。
建议方向
至少三条,不预设结论:
- A. 让它报错而不是静默退化:若包级
test脚本能检出"传了路径但一个都没匹配上",就 exit 非零。最小改动,直接消除"安静跑错东西"。 - B. 在 AGENTS.md / 测试文档里写明正确调用方式,并说明包级过滤 + 路径不生效。成本最低,但只对读文档的人有效。
- C. 让包级
test脚本正确转发路径(把相对路径改写成仓根相对)。最彻底,但要确认不会破坏现有调用方式。
倾向 A + B(让错误方式响亮失败,同时把正确方式写下来);C 更彻底但需要评估 turbo / vitest 两层的转发行为。
发现路径:objectui#3275 / PR #3285 的验证。
Activity
yinlianghui commentedon Aug 5, 2026
在 #3314(PR #3369)的验证里又撞到同一族,并且拿到一条比标题更强的证据 —— 不是「带路径时路径被忽略」,而是不带任何路径的包级
test本身就跑错了包。复现
在
objectui-issue-3314worktree(baseorigin/main@68b6a28)里:两个完全不同的包,逐字相同的 20 / 184。header 里还煞有介事地打印
RUN v4.1.10 …/packages/core与…/packages/react。用
vitest list把收集到的文件打出来,才看到跑的是什么: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 与各处派发提示都把「只跑受影响的包」写成推荐做法。
正确跑法(本轮实际用的)
从仓库根:
CI 不受影响:
.github/workflows/ci.yml明确注释了要跑根 vitest project(
pnpm test --shard=…/4)而不是turbo run test,所以覆盖在 CI 里是全的 ——被坑的只有本地/agent 的包级调用。
对建议方向的一点补充
原 issue 的 A(匹配不到就非零退出)在这个形态下不够 —— 这里不带路径,也就没有
「传了路径却匹配不到」可检。更贴的是:包级
test脚本要么在启动时校验「本包至少收集到 1 个属于本包的文件,否则报错」,要么干脆把包级脚本改成从仓根调用
并注入本包路径(原 C)。
passWithNoTests: true在这里正是把信号吃掉的那一环。发现路径:#3314 / PR #3369 的验证。
Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
认领: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
fix(test): 拒绝两种静默假绿的 vitest 调用,并把正确跑法写进 AGENTS.md (objectstack-ai#3378,
fix(test): runner 的包级 test 入口指回仓根配置,不再落到 app 的 vite.config (objectsta…