修 #3584 时,按该单正文要求的「顺带确认紧随其后的 pnpm site:dev / pnpm site:build 两条命令仍然有效」做核验。那两条确实有效(根 package.json 里都在,#3584 的 PR 已如实记录)。但把同样的核验推到全文后,发现更靠前的另一节里三条命令全是死的 —— 该处不在 #3584 的文件面内(PM 认领评论把面锁死在 ### Writing Documentation 那一句 ± 最小相邻散文),按 Prime Directive #10 未在那个 PR 里修,另立本单。
现文(CONTRIBUTING.md:81-92,### Running Development Servers)
# Run the visual designer demo
pnpm designer
# Run the prototype example
pnpm prototype
# Run documentation site
pnpm docs:dev
与现状对不上
根 package.json 的 scripts 里这三个名字一个都没有。可运行的文档站命令是 site:dev / site:build / site:start(即 #3584 那节里写的那两条),docs: 前缀下只剩 docs:api 与 docs:check-links。
这一节是「Development Workflow」的开头,是新贡献者装完依赖后第一批照抄的命令,三条会连着报 Command "designer" not found。其中 docs:dev 与 #3584 是同一类搬迁滞后:docs: 前缀的站点脚本已改名到 site:,散文没跟上。
复现(只读,离线)
sed -n '81,92p' CONTRIBUTING.md
pnpm run | grep -E '^\s*(designer|prototype|docs:dev)\b' # => 无输出
node -e "console.log(Object.keys(require('./package.json').scripts).filter(s=>/^(site|docs):/.test(s)))"
# => [ 'site:dev', 'site:build', 'site:start', 'docs:api', 'docs:check-links' ]注:grep -rl '"designer"' --include=package.json packages 会命中 packages/plugin-designer/package.json,那只是包名 @object-ui/plugin-designer 里的子串;该包的 scripts 是 build / clean / test / type-check / lint,没有 designer。也就是说没有任何 workspace 包能让 pnpm designer 从根跑通。
为什么门禁抓不到
与 #3584 同源:这是围栏内的命令名断言,不是链接。check-doc-links.mjs 的 stripCode() 在扫描前会把围栏整块抹掉(这正是相对链接检查得以安全开启的前提),所以哪怕 #3572 / PR #3589 把 CONTRIBUTING.md 加进 SCAN_ROOTS,这三行照样不可见 —— PR #3589 自己也量到过:该文件 25 条链接里 10 条在围栏内、门禁真正判定的只有 1 条。仓库里目前没有任何检查会因为散文里的 pnpm SOMENAME 不存在而变红。
建议
按现有 script 名改写这三条,或删掉已无对应入口的示例。修之前需要先定:designer / prototype 两个 demo 今天到底还有没有等价入口(可能是 pnpm --filter ... dev、可能已随示例应用移走、也可能确实退役了)—— 这一步是事实调查,不宜靠猜,本单未替未来的实现者做决定。docs:dev 一条没有歧义,直接就是 site:dev。
顺带可考虑的根治方向(不属于本单,若要做请另立):给散文里的 pnpm SOMENAME 加一条轻量门禁,把命令名与根 package.json 的 scripts 对账 —— 上面那段 node -e 已经是它的雏形。这类「围栏内的事实断言」目前是整块盲区,#3584 与本单是同一盲区的两个实例。
(注:上两段原写作尖括号占位符,被 GitHub 的 body sanitizer 当作 HTML 标签吞掉了,现改为 SOMENAME。这正是 objectstack#5140 家族那条「PR/issue 正文里避开尖括号紧跟字母,并回读存档正文」的实例。)
关联
#3584(同文件、同类过期陈述,docs: → site: 同一次改名的另一半)、#3570 / PR #3585 与 #3545 / PR #3571(同文件近期改动)、#3572 / PR #3589(SCAN_ROOTS 扩面 —— 即使落地也够不到围栏内)。
⚠️ 本单未认领,留给 PM 分诊。发现于 #3584 的核验步骤,未在其 PR 中修改。
修 #3584 时,按该单正文要求的「顺带确认紧随其后的
pnpm site:dev/pnpm site:build两条命令仍然有效」做核验。那两条确实有效(根package.json里都在,#3584 的 PR 已如实记录)。但把同样的核验推到全文后,发现更靠前的另一节里三条命令全是死的 —— 该处不在 #3584 的文件面内(PM 认领评论把面锁死在### Writing Documentation那一句 ± 最小相邻散文),按 Prime Directive #10 未在那个 PR 里修,另立本单。现文(
CONTRIBUTING.md:81-92,### Running Development Servers)与现状对不上
根
package.json的scripts里这三个名字一个都没有。可运行的文档站命令是site:dev/site:build/site:start(即 #3584 那节里写的那两条),docs:前缀下只剩docs:api与docs:check-links。这一节是「Development Workflow」的开头,是新贡献者装完依赖后第一批照抄的命令,三条会连着报
Command "designer" not found。其中docs:dev与 #3584 是同一类搬迁滞后:docs:前缀的站点脚本已改名到site:,散文没跟上。复现(只读,离线)
注:
grep -rl '"designer"' --include=package.json packages会命中packages/plugin-designer/package.json,那只是包名@object-ui/plugin-designer里的子串;该包的 scripts 是build/clean/test/type-check/lint,没有designer。也就是说没有任何 workspace 包能让pnpm designer从根跑通。为什么门禁抓不到
与 #3584 同源:这是围栏内的命令名断言,不是链接。
check-doc-links.mjs的stripCode()在扫描前会把围栏整块抹掉(这正是相对链接检查得以安全开启的前提),所以哪怕 #3572 / PR #3589 把CONTRIBUTING.md加进SCAN_ROOTS,这三行照样不可见 —— PR #3589 自己也量到过:该文件 25 条链接里 10 条在围栏内、门禁真正判定的只有 1 条。仓库里目前没有任何检查会因为散文里的pnpm SOMENAME不存在而变红。建议
按现有 script 名改写这三条,或删掉已无对应入口的示例。修之前需要先定:
designer/prototype两个 demo 今天到底还有没有等价入口(可能是pnpm --filter ... dev、可能已随示例应用移走、也可能确实退役了)—— 这一步是事实调查,不宜靠猜,本单未替未来的实现者做决定。docs:dev一条没有歧义,直接就是site:dev。顺带可考虑的根治方向(不属于本单,若要做请另立):给散文里的
pnpm SOMENAME加一条轻量门禁,把命令名与根package.json的scripts对账 —— 上面那段node -e已经是它的雏形。这类「围栏内的事实断言」目前是整块盲区,#3584 与本单是同一盲区的两个实例。(注:上两段原写作尖括号占位符,被 GitHub 的 body sanitizer 当作 HTML 标签吞掉了,现改为
SOMENAME。这正是 objectstack#5140 家族那条「PR/issue 正文里避开尖括号紧跟字母,并回读存档正文」的实例。)关联
#3584(同文件、同类过期陈述,
docs:→site:同一次改名的另一半)、#3570 / PR #3585 与 #3545 / PR #3571(同文件近期改动)、#3572 / PR #3589(SCAN_ROOTS扩面 —— 即使落地也够不到围栏内)。