fix(plugin-report): 放宽 react/react-dom peer 到 ^18.0.0 || ^19.0.0,对齐其余 29 个包 (#3690) - #3727
Conversation
…ckage pinned to 18 alone (#3690) `peerDependencies.react` and `peerDependencies.react-dom` widen from `^18.0.0` to `^18.0.0 || ^19.0.0`, matching the other 29 packages in the fixed version group. With npm 7+ resolving peers strictly, a React 19 consumer installing the published package hit an ERESOLVE on first install while every sibling installed clean; the package README already documented the wider range, so the manifest was the half that was wrong. Three probes, run before the edit, all pointing the same way: 1. History. No batch commit ever added `|| ^19.0.0` to 28 packages, so the dispatch's "predates the batch and was missed" mechanism does not exist. The wide range is the repo's birth convention since 2026-01-14, applied per package at creation. plugin-report's manifest was hand-authored 2026-02-06 (1e557cb) when nineteen siblings already carried the wide range, and every package created afterwards was born with it. The only other narrow-born package, plugin-dashboard, was corrected 2026-05-08 (d2b6ece) in a build fix touching only itself. No commit in the file's 172-commit history revisited the peer line; none mentions a React 18 requirement. 2. API surface. Zero uses of anything React 19 removed. The package's whole React surface is React.FC, useState, useEffect, useMemo, useReducer, useContext, Fragment, ComponentType, CSSProperties, ReactNode. react-dom is never imported by the source; it appears only as a UMD global name in the Vite externals. 3. Empirical. The workspace pins react to 19.2.8 via a root pnpm.overrides, and plugin-report resolves that build, so its 78 tests have been running under React 19 the whole time the manifest said 18 only. Also flips the plugin-report row in scripts/__tests__/doc-version-claims.test.ts from `kind: 'stale'` to `restatement`: that ledger row recorded the README as wrong-versus-manifest, and widening the manifest makes the README's existing text true without editing a character of prose. Header counts go from nine stale rows to eight. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
冲突只有一处:scripts/__tests__/doc-version-claims.test.ts。PR #3726(fbf7d6d) 在同一文件上清偿了 #3708/#3709/#3710 的 8 条失真,KNOWN_CLAIMS 27 → 21、stale 9 → 1(刻意留下的那条就是 plugin-report,修法在清单侧,归本单)。 三段冲突按并集语义在 #3726 之后的新形态上重写,而不是把本分支的旧文本贴回去: - 条目区(第三段):两侧各自删掉了自己那条 stale——main 删的是 layout(#3710 已把 README 的 `>= 18.0.0` 收窄成清单拼写),本分支删的是 plugin-report。 删除的并集就是整块去掉。layout 那条必须删:它指的宣称已不在树里,留着会让 「no entry may outlive the claim it excuses」这条棘轮红。plugin-report 那条也 必须删:本分支新增的 restatement 单行与它 keyOf() 完全相同,两条并存会撞上 「KNOWN_CLAIMS has duplicate entries」。 - 两段散文:改以 main 的事实清单为底(谁清偿了哪几条),把计数按合并后文件的 真实行重算。本分支原来写的「NINE → eight」在 #3726 之后本身已经过期。 计数逐行数出来,不靠推断:合并后 21 条(与 main ±0),restatement 12 → 13, stale 1 → 0。逐行比对 main 与解析结果的行集合,唯一差异是 `packages/plugin-report/README.md :: stale` → `:: restatement`,没有任何文件被 整条丢掉——即 #3726 的 9 条清偿全部完好过桥。另外同步了两处非冲突但被本次翻转 写旧的注释:restatement 类「12 of 21」→「13 of 21」,PEER_18_19 头注的「10 个 README / 第十一个 plugin-report 仍是 stale」→ 11 个,并说明它是从相反方向 (改清单而非改散文)加入的。 清单侧重新核对(一行读):packages/plugin-report/package.json 的 peerDependencies 现为 react / react-dom 皆 `^18.0.0 || ^19.0.0`,README:24-25 逐字相同,故 restatement 的 why 文本成立。package.json 与 changeset 均干净合并。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt
已合并 main 并补齐上文交代的验证缺口(commit
|
| 探针 | 预判 | 实测 |
|---|---|---|
| A 恢复 layout 那条 stale(我删掉的 HEAD 一侧) | 红,且应由「no entry may outlive the claim it excuses」点名 | 红,如预判:AssertionError: KNOWN_CLAIMS names version claims that are no longer in the tree: - packages/layout/README.md :: react >= 18.0.0`,1 failed / 5 passed |
| B 两条 plugin-report 并存(改用「并集=相加」) | 红,且应由重复键断言点名 | 红,如预判:AssertionError: KNOWN_CLAIMS has duplicate entries: expected 21 to be 22 |
C 单把 kind 翻回 stale(清单仍是宽范围) |
绿 —— 不动,因为没有任何断言读 .kind |
绿,6 passed,如预判 |
C 这一格据实写明,不造红绿:grep 全文确认没有任何 expect 读取 .kind,该字段只受 ClaimKind 联合类型约束。这与本文件头注自己的说法一致 —— restatement 类命名的等价关系「由人读清单复核,而不是本门禁」。所以 A/B 证明的是解析的删除那一半是必需的、不是顺手,而 kind 翻转本身是记账性的,由第一节那次一行清单复核背书。
worktree 按约定保留,待 PM 确认落地后再清。auto-merge 未由我重新武装。
Generated by Claude Code
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
@object-ui/plugin-report 声明了 react-dom peer 却从未 import 它——仅作为 UMD 全局名出现在 vite.config externals
#3740
Fixes #3690
@object-ui/plugin-report的peerDependencies.react/react-dom从^18.0.0放宽到^18.0.0 || ^19.0.0,与固定版本组里其余 29 个包对齐。npm 7+ 严格解析 peer,React 19 使用者装这个已发布包(17.3.0)会在首次 install 撞ERESOLVE,而 29 个兄弟包全部装得干净。该包 README 早就写着放宽后的范围 —— 错的一直是清单这一侧。PM 裁决的三探针在动手之前逐一实测,全过。这类改动的「验证」就是探针本身:peer 范围是发布元数据,不进任何代码路径,不存在「改前红、改后绿」的断言可写。下面据实写探针输出,不造模板红绿。
探针一 · git 历史 —— 过,但机制与派发预设的不同
派发预设的形状是「28 个兄弟包批量加
|| ^19.0.0,plugin-report 早于该批量且被漏改」。这个批量提交不存在。 据实报账:仓库是 shallow clone(211 commits,graft 点
30ac2e1ee把每个文件都显示成 new file),必须git fetch --unshallow(7516 commits)才能看清。展开后:宽范围不是某次批量补的,而是仓库从 2026-01-14 起的出生约定,逐包在创建时写入。在 plugin-report 创建的那个切点上量所有包:
创建于 plugin-report 之后的每一个包都是出生即宽 —— 相隔仅两三天的也一样:
另一个出生即窄的
plugin-dashboard在 2026-05-08 被d2b6ecec6(fix(build): externalize all bare imports in library builds)改正:那次只碰了 plugin-dashboard 一个 package.json(
git show --name-only d2b6ecec6 | grep package.json只有一行),是定点修,不是批量 —— 所以 plugin-report 没被捎上。逐包扫「出生即宽 / 后来变宽」,plugin-report 是唯一一个声明了 react peer 却从未拿到宽字符串的包;它 172 次提交的历史里没有任何一次动过 peer 行,创建提交的正文(六条 bullet,讲 ReportRenderer/ReportViewer/ReportBuilder/测试/注册/构建配置)也没有一个字提到 React 版本约束。
方向判定:过。 探针要回答的是「窄范围是不是被记录过的刻意约束」,答案是否 —— 它是一份手写 package.json 偏离了当时已成立的约定,此后无人回访。机制与预设不同,结论同向,故按裁决继续;预设错的那一半在此如实写明。
探针二 · API 面 —— 过,零命中
正向清点该包用到的全部 React 面(4087 行,10 个源文件):
全部在 React 19 未变。
React.FC我故意放进了 grep 当近似项:它不是 19 移除的 API(变的是@types/react里FC不再隐含children),而该包自己的 devDependencies 就是@types/react: 19.2.18,已在 19 的类型面上编译。附带量到:
react-dom在源码里从未被 import,只作为 UMD 全局名出现在vite.config.ts:46的 externals('react-dom': 'ReactDOM')。已另立观察级 finding,本 PR 仍按裁决同步放宽它 —— 保持固定组内一致优先于顺手裁剪 peer。探针三 · 经验证据 —— 过
根
package.json的pnpm.overrides把整个 workspace 钉在 19.2.8:plugin-report 自己没有
devDependencies.react,实测它解析到的就是这一份:改动之前跑基线(此时清单仍写
^18.0.0):也就是说这 78 个测试一直在 React 19 下跑,而清单一直声明它不支持 19。实证兼容。
改动面
packages/plugin-report/package.jsonreact/react-dompeer →^18.0.0 || ^19.0.0scripts/__tests__/doc-version-claims.test.tskind: 'stale'→restatement,并把头注里的「NINE stale」修成八.changeset/plugin-report-react-19-peer-3690.mdmajor,合仓规README 一个字都没改,这是对的。
packages/plugin-report/README.md:24-25本来就写着正如 #3711 在本单下的追评所判:是清单落后于 README,清单改对之后 README 自动为真。这也是九条 stale 债里最便宜的一条 —— 修锚点,不改句子。
pnpm-lock.yaml零 delta,这是构造性的,不是漏跑。 跑了pnpm install --lockfile-only,结果与origin/main逐字节相同。原因可机械核验:pnpm lockfile 的importers段对 workspace 包只记dependencies/devDependencies,从不记peerDependencies——所以 workspace 包改 peer 范围按构造不产生 lockfile 变化。据实写明,免得下一个读者以为这步被跳过了。
ledger 并行注记(#3708 在途也动同一文件)。 已复核在途 PR:#3708 与 #3709 目前都没有开着的 PR(仓内在途 PR 只有 #3691 / #3598 / #3580,均不碰此文件)。因此我只动了
packages/plugin-report/README.md那一行,architecture-overview/architecture.md/create-plugin.mdx的六条 stale 行原样保留,留给 #3708 / #3709。头注的 stale 计数我从九改成八 —— 那两单落地时会各自再减,数字在同一句里,是行级冲突,取并集即可。测试
一处如实交代:
pnpm --filter @object-ui/plugin-report type-check在本 worktree 未跑绿,报的是这是新建 worktree 里 workspace 依赖没 build 的既有状态,不是本改动引起,两点可证:(1) 实测
packages/fields/dist、packages/components/dist、packages/react/dist、packages/plugin-grid/dist在本 worktree 里不存在,tsc走 packagetypes→dist/index.d.ts因而解析不到,vitest 走源码 alias 所以照绿;(2) 本 PR 的 diff 只有一个peerDependencies块(tsc从不读它)和一个scripts/测试文件(type-check:scripts已 exit=0),结构上不可能产生 workspace 模块的 TS2307。补齐它需要pnpm --filter '@object-ui/plugin-report^...' build,我在容器里发起该构建时被打断,未重试。CI 每次全新安装并按拓扑先 build 依赖,会覆盖这一格 —— 但我不把它记成我跑绿的,请以远端为准。🤖 Generated with Claude Code
https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt
Generated by Claude Code