17 个包各自带 vitest.config.ts 与根 vitest.config.mts 行为分叉:先回答「哪些包真的需要本地配置」

[xuyushun441-sys]

越界发现,自 objectui#3219 拆出(Prime Directive #10)。未认领,需先由维护者定方向再动手。

#3219 只修了一个文件的 mock 写法(plugin-calendar/src/registration.test.tsx),并钉了一条断言防止该文件再次分叉。但产生分叉的机制是仓库级的,仍然存在,只是暂时没有别的文件踩中。

分叉机制(在 #3219 里已实测坐实,不是推测)

本仓有两套 vitest 配置,对同一个测试文件可以给出不同结论:

路径	实际执行	@object-ui/* 解析到
CI(.github/workflows/ci.yml)	根 package.json 的 "test": "vitest run" + --shard=N/4,走根 vitest.config.mts 的 projects/alias	源码(resolve.alias 把 ~40 个包名指向 packages/*/src)
pnpm --filter < pkg > test / turbo run test	该包自己的 vitest.config.ts	dist(无 alias,走 workspace 包的 exports,因此 test 任务 dependsOn: ["^build"])

plugin-calendar 的实测形态:同一份 registration.test.tsx,根配置 2 passed,包配置 suite 根本加载不了(No "subscribeDataChanges" export is defined on the "@object-ui/react" mock)。

更值得注意的是,根配置那一侧的"绿"是偶然的:该文件在根配置的 heavyDomTests 名单里,vitest.setup.dom.tsx 会预先 import '@object-ui/components',于是 components/src/hooks/related-count-store.ts(它 import 了 subscribeDataChanges)在 vi.mock 生效之前就已按真实模块求值完毕;包配置没有这个 setup,@object-ui/components 首次求值发生在被 mock 的图里,于是炸。也就是说两侧的差异不止 alias,还叠加了 setupFiles 是否预热了消费者模块——两个独立变量。

后果

1. AGENTS.md 建议本地只跑受影响的包,但那条路径与 CI 结论不等价:今天方向是假警报(plugin-calendar 的 registration.test.tsx 在 main 上就是红的:@object-ui/react 的 vi.mock 缺 subscribeDataChanges #3219 就是这么产生的,浪费一轮诊断),反方向就是真失败对 CI 不可见;
2. turbo test 全量在本地长期红,于是"全量绿"在本仓对不同人意味着不同的东西;
3. 与 turbo run type-check --filter=@object-ui/plugin-detail 必定失败:@object-ui/permissions 只在 peerDependencies,^build 因此不构建它 #3207(turbo type-check --filter 恒失败、全仓跑时不可见)同族——门禁在特定调用方式下给出的答案不作数。

涉及的 17 个包(实测清单)

components, core, fields, plugin-calendar, plugin-charts, plugin-dashboard, plugin-detail, plugin-form, plugin-gantt, plugin-grid, plugin-kanban, plugin-list, plugin-map, plugin-timeline, plugin-view, react, types

即 ls packages/*/vitest.config.* 的全部结果。

动手前必须先回答的问题

哪些包"真的需要"本地 vitest 配置?

在这个问题有答案之前不要动手改配置面。可选方向,各自代价不同:

• A. 全删,统一由根配置跑。 最彻底,一套配置一个结论,dist 与源码的解析差异随之消失。代价:pnpm --filter < pkg > test 这个用法要重新定义(改成对根配置传路径过滤),turbo 的 test 任务与 ^build 依赖也要重估;需要逐包确认没有哪个包依赖本地配置里的特殊 environment/setup。
• B. 保留但强制继承根配置(本地 config extends 根 alias/setup),只允许覆盖确有必要的字段。代价:仍是两个入口,只是把分叉面收窄;要有机械检查防止漂移。
• C. 保留现状,逐个文件像 plugin-calendar 的 registration.test.tsx 在 main 上就是红的:@object-ui/react 的 vi.mock 缺 subscribeDataChanges #3219 那样加断言。 成本随文件数线性增长,且只在有人踩中之后才发现——不推荐,记在这里只为完整。

倾向 A 或 B,但需要维护者先定:这是一次跨 17 个包的配置面重构,会与在飞单大面积撞文件,应单独排一轮、不与其他改动同批。

不要混进来的一件事

#3219 里附带提到 @object-ui/plugin-gantt 的 ELIFECYCLE(单独跑 35 文件/340 断言全绿)是并发内存压力形态,与本条的配置分叉不是一回事。

---

Restart-when: no pm:dispatched card exists in the domain:devx @ objectui lane — i.e. no dev in flight, the 2026-08-10 ruling's "single dev, no other work in flight", evaluated at the moment of dispatch. The ruling's other clause, "board drained or near-drained", is satisfied while the only remaining pm:queue work is the rolling #5174 ledger batches: that card cycles indefinitely by design, so treating it as blocking would make this condition unreachable. Executable check: list open issues labelled domain:devx in this repo and confirm none carries pm:dispatched.

Line added 2026-09-03 by the domain:devx execution seat (R42) to make an already-ruled restart condition machine-readable; it restates the 2026-08-10 ruling and ⛔ does not change it. Corrected the same day — the first version also required zero other pm:queue cards, which dropped the ruling's "or near-drained" and made the condition unreachable while #5174 cycles. See the comments below.

[xuyushun441-sys]

补一条测量,供排期时估算爆炸半径。

#3219 修的那种整模块 vi.mock('@object-ui/react', …) 写法,在本仓共有 30 个测试文件(含刚修好的 plugin-calendar/src/registration.test.tsx):

$ grep -rln "vi.mock('@object-ui/react'" packages/ --include=*.test.tsx --include=*.test.ts | wc -l
30

分布(部分):plugin-kanban、plugin-detail ×7、plugin-view ×3、plugin-gantt、app-shell ×多个、plugin-calendar。

这不等于 29 个文件现在都是红的 —— 是否炸取决于三件事同时成立:该文件所在配置路径、有没有 setupFiles 预热了消费者模块、以及它的传递依赖恰好用到了 mock 里没列的导出。plugin-calendar 只是第一个三者凑齐的。但每新增一个 @object-ui/react 导出、或某个包的 setup 名单一变,都可能把其中任意一个翻红,且翻红方式仍然是"一条路径红、另一条绿"。

对本 issue 的两点含义:

1. 选项 A/B(统一或强制继承根配置)的收益比看起来大 —— 它让这 30 个文件至少在两条路径下结论一致,红要一起红;
2. 但配置统一并不能单独解决整模块 mock 的脆弱性:即使只剩一套配置,整模块 mock 仍会在下一个新增导出时失效,只是不再"一路红一路绿"而已。真正的根治要两步:配置统一 + 把这 30 处改成 importOriginal 部分 mock(或加一条 lint 规则禁止对 workspace 包做整模块 mock)。

#3219 用的断言写法可以直接复用为模板(比较导出集合、不点名具体导出):

const actual = await vi.importActual< typeof ObjectUIReact >('@object-ui/react');
const missing = Object.keys(actual).filter((name) => !(name in ObjectUIReact)).sort();
expect(missing).toEqual([]);

不过 30 处逐个加断言是选项 C 的成本形态(线性、且只在踩中后才发现);更划算的大概率是一条 lint 规则。未认领,仍待维护者定方向。

---

Generated by Claude Code

[yinlianghui]

转决策收件箱:needs-user-decision(objectui 分片 PM,会话 session_01GTRjn8xBqp75dk7kFupVRt)。

要拍板的一句话:17 个包的本地 vitest.config.ts 是全删统一走根配置(方案 A),还是保留但强制继承根配置(方案 B)?

两轴分析:

• 项目长远合理性:A 最彻底——一套配置一个结论,dist/源码解析分叉与 setupFiles 预热差异一次性消失;代价是 pnpm --filter <pkg> test 语义要重定义、turbo test 的 ^build 依赖要重估。B 保住既有入口但分叉面只是收窄,需要机械检查防漂移——多一个需要长期维护的守卫。
• 防 AI 犯错:两案都远好于现状(现状=同一文件两套结论,plugin-calendar 的 registration.test.tsx 在 main 上就是红的:@object-ui/react 的 vi.mock 缺 subscribeDataChanges #3219 实测坐实)。A 结构性消灭「在哪跑」这个自由度,AI 无从跑错;B 仍留两个入口,靠守卫兜底。倾向 A,但它是跨 17 包的配置面重构、与在飞单大面积撞文件,须单独排一轮空批次执行——这正是需要你定 appetite 的原因。

过渡期已止血:第 33 单(#3378+#3288)只做「错误调用方式响亮失败 + 文档」,不动配置面,与本决策不冲突、先行落地。

---

Generated by Claude Code

[xuyushun441-sys]

维护者裁决（2026-08-06，经 PM 会话 session_01MN3ao9kJEtD7PNAKwFVp96 转达）：A —— 全删 17 个包的本地 vitest.config，统一走根配置。执行约束：

• 单独排一轮空批次执行（跨 17 包配置面重构，与任何在飞单不同批）；
• 同单重定义 pnpm --filter <pkg> test 的语义（对根配置传路径过滤），并重估 turbo test 任务的 ^build 依赖；
• 逐包确认没有依赖本地配置的特殊 environment/setup，有则迁进根配置的 projects；
• 30 处整模块 vi.mock('@object-ui/react', …) 的脆弱性是独立问题：配置统一后补一条 lint 规则（禁止对 workspace 包整模块 mock / 强制 importOriginal），单独立单，⛔ 不塞进本单。

摘 needs-user-decision，回 pm:queue；已在飞的止血单（#3378+#3288，响亮失败+文档）先行落地，与本裁决不冲突。

---

Generated by Claude Code