test(plugin-calendar): partial-mock @object-ui/react so both vitest configs agree (#3219) - #3241
Merged
xuyushun441-sys merged 1 commit intoAug 3, 2026
Conversation
…onfigs agree (#3219) `registration.test.tsx` whole-module-mocked `@object-ui/react` with just `useSchemaContext` + `SchemaRendererContext`. That made the file's result depend on how the module graph resolved, so the repo's two vitest configs disagreed about it: - root `vitest.config.mts` (CI): the file is in `heavyDomTests`, and `vitest.setup.dom.tsx` eagerly imports `@object-ui/components`, which evaluates `related-count-store.ts` (imports `subscribeDataChanges` from `@object-ui/react`) against the REAL module before the mock applies — green by accident. - `packages/plugin-calendar/vitest.config.ts` (`pnpm --filter … test`, `turbo run test`): no such setup, so `@object-ui/components` is first evaluated inside the mocked graph. Vitest 4 hard-errors on a missing export, so the suite failed to load at all. Switch to an `importOriginal` partial mock: the mock is now a superset of the real module under either resolution, so a transitive consumer can never trip over an export this test never intended to replace. Add a regression guard asserting the mock exposes every real export. It compares export SETS rather than naming `subscribeDataChanges`, so adding a new `@object-ui/react` export cannot re-arm the same trap. Verified to fail on the root path — the path where the original defect was invisible. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NVPjPzmmAJ2Ngtvgg5MSRa
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
xuyushun441-sys
marked this pull request as ready for review
August 3, 2026 07:15
xuyushun441-sys
deleted the
claude/issue-3219-calendar-mock-importoriginal
branch
August 3, 2026 07:16
This was referenced Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3219
按 PM 在认领评论里的裁定,本 PR 只做两件事:把
registration.test.tsx改成importOriginal的部分 mock,并补一条断言钉住这个文件在两条运行路径下结论一致。全仓 17 个包的 vitest 配置治理不在本单,已另立 #3240。根因(实测坐实,不是推测)
同一份
packages/plugin-calendar/src/registration.test.tsx,两套配置结论相反:vitest.config.mts,vitest run --shard=N/4)@object-ui/*alias 到源码pnpm --filter @object-ui/plugin-calendar test/turbo run test(包内vitest.config.ts)dist原来的写法是整模块替换,只列了
useSchemaContext+SchemaRendererContext。真正 importsubscribeDataChanges的不是 plugin-calendar 自己,而是传递依赖@object-ui/components的src/hooks/related-count-store.ts。关键的一层:根配置那一侧的"绿"是偶然的。该文件在根配置的
heavyDomTests名单里,vitest.setup.dom.tsx会预先import '@object-ui/components',于是related-count-store.ts在vi.mock生效之前就已按真实模块求值完毕;包配置没有这个 setup,@object-ui/components首次求值发生在被 mock 的图里,vitest 4 对整模块 mock 的缺失导出是硬报错(不再静默给undefined),于是整份文件加载失败。所以分叉有两个叠加变量:alias 解析目标(源码 vs
dist),以及 setupFiles 是否预热了消费者模块。修法
改用
importOriginal的部分 mock,只覆盖这份测试真正要控制的useSchemaContext:这样 mock 在任一解析路径下都是真实模块的超集,传递依赖不可能再撞上一个本测试从未打算替换的导出。
SchemaRendererContext不必再手写——原模块的那个会被 spread 进来。vi.mock('./ObjectCalendar', …)保持整模块替换:那是本测试刻意的隔离边界(且该模块唯一的运行时导出就是组件本身,ObjectCalendarProps是类型、运行时已擦除)。防回归断言
新增一条断言,钉的正是"分叉"本身的不变式——mock 必须是真实模块的超集:
刻意比较导出集合而不是点名
subscribeDataChanges:点名只会把同一个陷阱推迟到下一个新增导出(这正是原 issue 指出的问题)。该不变式成立时,任何传递 importer 都不会遇到缺失导出,于是文件在哪套配置下解析、setup 有没有预热消费者,结论都一样。验证
修复前,包路径(issue 报告的那条):
修复后,两条路径一致:
包全量:
Test Files 3 passed (3)/Tests 16 passed (16)(原为1 failed | 2 passed)。type-check通过,lint0 error。断言的反向验证(把整模块 mock 改回去,断言留着):
两条路径同红同绿,断言确实拦得住。
关于 changeset
未加,理由:本 PR 只改动一个
*.test.tsx,不进dist(包的files只发dist/README/CHANGELOG),对使用者零可见变化。按 AGENTS.md「功能改进需写 changeset;纯 bug 修复不需要」,测试基础设施修复比纯 bugfix 更靠内。加了反而会让fixed组 39 个包为一次测试改动整体升版。如维护者认为仍需登记,我补一条patch即可。越界发现
vitest.config.ts与根vitest.config.mts的分叉治理(评论里"删掉本地配置比修好它更彻底"那条方向)。已按 Prime Directive [WIP] Enhance every detail of the designer #10 不认领立单,正文写明本 PR 坐实的分叉机制、17 个包清单,以及动手前必须先回答的问题「哪些包真的需要本地配置」。未在本 PR 处理:那是跨 17 个包的配置面重构,会与本轮在飞单大面积撞文件。plugin-ganttELIFECYCLE未追:issue 自述是并发/内存漂移,与本条不是一回事。🤖 Generated with Claude Code
https://claude.ai/code/session_01NVPjPzmmAJ2Ngtvgg5MSRa
Generated by Claude Code