docs(guide): plugin skeleton 声明 @vitejs/plugin-react,并把该行入版本声称锚 (#4961) - #4985
Conversation
Step 5 of the numbered plugin tutorial writes vite.config.ts with `import react from '@vitejs/plugin-react'` and calls react() in plugins; step 6's devDependencies never declared it, and that import was the only mention of the package on the page. A reader following 1-6 hit their first `pnpm build` with a config importing something they were never told to install. Declares it at ^6.0.5 - the range all 19 in-repo plugin manifests declare unanimously. The literal is anchored rather than recorded: a third `anchored` KNOWN_CLAIMS entry carrying skeletonDep, which #3855's derived floor absorbs without a new mechanism. Deliberately untouched on the same block: the peerDependencies react range (owned by the copied plugin's author) and the absence of vite-plugin-dts (declarations come from tsc --emitDeclarationOnly). Co-authored-by: Claude <noreply@anthropic.com>
|
PM 验收 ✅ ACCEPT(#4961,批次 20) 实物核验(按真实 merge-base 对账):3 files,+86/−10 —— CI 亲读:19/19 check runs completed,零失败(dependabot/coverage 两项 path-filter skipped 计绿;shard 2 12:37:53Z 收尾)。 偏差判定:卡面点名的 反向验证读数(四变异,两处方向与卡面预设相反、均如实报告):(2a) 只改 doc 的假版本够不到比对支路 —— inventory key 内嵌版本字面量,先被孤儿化棘轮抓住,与 #4963 变异 A 同构;(2b) doc+key 同步改 → 恰 1 红且报错点名 边界核验:peer range 保持 undraft + auto-merge(squash)。 Generated by Claude Code |
Fixes #4961
同文件串行门:PR #4963 在派发前已落 main(merged 11:58:37Z,分诊认领评论 11:58:50Z),无需等待循环。本分支从其落地 sha
7d1017790切出,用的正是它落地的skeletonDep机制。前提验证:成立,卡上三个测量值全部复核无漂移
三样都对着
7d1017790重新读过,没有沿用卡上的数字::340import react from '@vitejs/plugin-react',并在plugins: [react()]用掉:397-403,五条,无@vitejs/plugin-react:340一次 import 提到该包@vitejs/plugin-react ^6.0.5,19/19^6.0.5,19/19 全一致(逐个packages/plugin-*/package.json读过)卡上写的「锚现成且一致,不需要任何判断」成立。与 #4963 的经历不同,这次九天里锚没有漂 —— 但仍是重测过才敢用。
改法(两个文件 + 一条 changeset)
content/docs/guide/plugins.md:401的 devDependencies 增"@vitejs/plugin-react": "^6.0.5",按仓内 plugin 清单的字典序位置(@object-ui/types之后、typescript之前)。scripts/__tests__/doc-version-claims.test.ts:第三条kind: 'anchored'+skeletonDep: '@vitejs/plugin-react'的KNOWN_CLAIMS条目;两条真空下限 2 提到 3;resolves the anchor unanimously的派生下限名单加一个名字。没有新机制 —— docs(guide): plugin skeleton 的 vite/typescript 对齐仓内实测,并把该拼写纳入版本声称门 (#3855) #4963 第 3 个 commit 留的派生下限正是为这种后续新增设计的,这一单是它的第一个用户。## What objectui#4961 added。一处非显然的事实,值得点名而不是让下个读者踩
该行被扫出来的 claim key 是
react": "^6.0.5,不是@vitejs/plugin-react": "^6.0.5"。原因:React是TOOLCHAIN词,而@vitejs/plugin-react里react前面的-构成词边界,于是匹配从react起,记下的字面量是包名的尾巴,指向一个与该行实际声明不同的包。这恰好是
skeletonDep那段注释所说「dep 名写出来而不是从 claim 文本派生」的第一个真实用例 ——parseManifestLine读整行,所以比对仍然打在@vitejs/plugin-react上(见下方变异 ②b/③ 的红法,报的是@vitejs/plugin-react而非react,这就是机械证据)。条目上加了行内注释说明。逆向验证:四个变异,方向都先预测后跑;两个的方向与任务卡的预设不一致,据实回报
任务卡给的两条是「①删掉新增行 → 骨架断言红;②版本改假值 → 锚红」。①如预期;②按字面做到不了锚的比对支路,原因是结构性的,与 #4963 变异 A 同一条:清单键内嵌版本字面量。下面把两半分开跑。
变异 ① —— 临时删掉新增的 doc 行
预测:红 2 条,且骨架断言的红来自「真空下限」而非比对支路 —— 字面量离开树 → 条目变孤儿(上行棘轮红);
skeletonChecks该项absent: true→ 比对循环故意跳过,但stated为空 → 比对行数和从 3 掉到 2,撞下限。逐条对上。「骨架断言红」成立,但红的是下限而不是比对 —— 据实写明,不套模板。
变异 ②a —— 只把 doc 里的值改成
^9.9.9(任务卡的字面读法)预测:红 3 条,锚的比对支路仍然跳过。 键含版本字面量,所以改值同时造出一条未记账的新 claim(下行棘轮)并让旧条目变孤儿(上行棘轮),该项再次
absent。所以「版本改假值 → 锚红」按字面做不成立:值被两个方向的棘轮先钉住了,比对支路根本没轮到。要真的动到锚,得让记下的字面量与 doc 行一致、而与仓内不一致 —— 即下面两个变异。
变异 ②b —— doc 值与清单键同步改成
^9.9.9(真实的误操作形状:页面和账本一起 bump 了,仓内没有)预测:恰好一条红,走比对支路,点名行号与两侧区间。
注意报的是
@vitejs/plugin-react,不是 claim key 里那个react—— 上文那段的机械证据。变异 ③ —— bump 全部 19 个 plugin 清单到
^7.1.0,文档留在原地这才是这条门存在的那个场景(下次仓升级同一行再化石化)。预测:恰好一条红走比对支路,且
resolves the anchor unanimously保持绿 —— bump 做完了就是一致的,只有文档旧,两条断言判两件不同的事。变异 ④ —— 抽掉新条目的
skeletonDep(证我扩的那条派生下限真的咬)预测:红 2 条 —— 计数下限 + 派生名单点名新 dep。
四个变异全部还原后复跑
18 passed,git status只剩本 PR 的三个文件。测试
新增字面量本身不新增测试条数 —— 它是被现成断言接住的,这正是 #4963 那半个交付物的目的;新增的覆盖体现在两条下限从 2 升到 3(变异 ①/④ 是它咬人的证据)。
消费半径扫过
按规则的调用者而非改动的包来扫:读
guide/plugins.md的除本门禁外只有check-doc-links.mjs及其测试,后者用自建内存 fixture('guide/plugins.md': '[Charts](...)'),不碰版本字面量。全仓 grepplugin-myfeature只命中本 PR 这两个文件。另外 grep 了全仓@vitejs/plugin-react的其它拼写面(packages/cli、packages/create-plugin的生成器测试、content/docs/utilities/cli.mdx),均未受本改动影响。顺带核过、明确没动的两处(卡面预核,复核后同意)
peerDependenciesreact/react-dom^18.0.0 || ^19.0.0:peer 说「拷走后向宿主接受什么」,由该插件作者拥有,与「在这里装什么来构建」是两件事。该条目照旧sample。vite-plugin-dts,而 19 个 plugin 包都有 —— 不是缺项:骨架 build 脚本是vite build && tsc --emitDeclarationOnly,声明文件由 tsc 自己出。两种写法都自洽。这一点在头部注释里写成了显式边界,因为这条断言正好邀请一个错误推论:它判的是页面已经命名的依赖的区间,不是「骨架该声明仓内清单声明的一切」。让 plugin-react 该在的理由不是它出现在清单里,而是 step 5 用了它 —— 页面自我矛盾,清单只在该行必须存在之后提供了区间。
另外两条纪律
content/docs/releases/**。越界发现(只记录、不顺手修)
doc-version-claims的SCAN_ROOTS是['content/docs', 'packages/*/README.md'],不含skills/,而skills/objectui/guides/下两份带package.json代码块的脚手架指南共 4 处版本字面量从未被任何门禁读过 —— 实测typescript ^5.0.0(差 1 个 major)、vite ^6.0.0(差 2 个)、@vitejs/plugin-react ^4.0.0(差 2 个)、lucide-react ^0.400.0(跨 major)。check-skills-paths.mjs确实扫 skills 但只判路径。这条比 content/docs 面更值得看:skills/是给 agent 读的面,化石会随每次脚手架复制进用户仓库。与 check-doc-links 扫描面漏掉包内非 README markdown:15 个文件的链接从未被任何门禁解析过(实测 1 条死链) #4938(check-doc-links 的扫描面洞)完全同形但不同 gate、不同文件集合,故独立立卡、未标 label,交 PM 分诊。另外核过但判定不是缺陷、故未立卡:
content/docs/guide/quick-start.md:45与building-crud-app.md:41同样import react from '@vitejs/plugin-react'却没有对应的 install 指令 —— 但这两页的第一步是pnpm create vite my-app --template react-ts,该模板自带@vitejs/plugin-react,所以 import 有着落,不是 #4961 那个形状。写在这里是因为「同一 import 出现在三页」很容易被机械判成三处同样的缺陷。🤖 Generated with Claude Code
https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt
Generated by Claude Code