turbo run type-check --filter=@object-ui/plugin-detail 必定失败:@object-ui/permissions 只在 peerDependencies,^build 因此不构建它 #3207

Activity

1. os-zhuang

   added

   pm:queue

   on Aug 2, 2026
2. xuyushun441-sys

   added

   pm:dispatched

   on Aug 3, 2026
3. xuyushun441-sys

   self-assigned this

   on Aug 3, 2026
4. xuyushun441-sys commented on Aug 3, 2026

   

   xuyushun441-sys

   on Aug 3, 2026 – with Claude

   Contributor

   More actions

   认领:PM 循环第 1 轮
   会话:session_01NVPjPzmmAJ2Ngtvgg5MSRa(objectui 分片 PM,账号 xuyushun441-sys,已在 objectstack#4604 登记)
   分支:claude/issue-3207-plugin-detail-permissions-dev-dep
   Worktree:objectui-issue-3207

   复核记录:体检已做,缺口有两处不是一处

   原单末尾说「顺手体检一下别的包有没有同样的 peer-without-dev 缺口」。我在 origin/main @ ca58e45 上跑了全仓体检,结果如下 —— 派发范围据此扩到两个包:

   @object-ui/plugin-detail -> missing: @object-ui/permissions
   @object-ui/plugin-list   -> missing: @object-ui/permissions
   

   (判据:peerDependencies 里的 @object-ui/* 未同时出现在 dependencies / devDependencies。全仓 packages/* 逐个扫,只有这两个包命中,其余包的 peer 都有对应 dev 边。)

   plugin-detail 的现场与原单描述完全一致:peerDependencies 五个 @object-ui/* 里,components / core / fields / react / types 都在 devDependencies,唯独 permissions 不在。plugin-list 是同一个缺口的第二例,原单没提到,一并修掉 —— 分开修没有意义,而且两处都改 package.json,分两单必然撞 pnpm-lock.yaml。

   验收补充

   turbo run type-check --filter=@object-ui/plugin-list 也要一并验证(改前应能复现同类失败或至少证明其依赖边完整),不要只验 plugin-detail。

   ---

   Generated by Claude Code
5. xuyushun441-sys commented on Aug 3, 2026

   

   xuyushun441-sys

   on Aug 3, 2026 – with Claude

   Contributor

   More actions

   PM 验收:ACCEPT — PR #3242,已入合并队列

   按 GitHub 实况逐条核对(不采信报告自述):

   项	结果
   PR 存在、targets main、Fixes objectstack-ai/objectui#3207	✅
   改动范围	✅ 4 个文件:两处 package.json 各 +1 行、pnpm-lock.yaml 重新生成、新增守卫测试
   content/docs/releases/ 零改动	✅
   CI	✅ 13 绿 + 2 skipped(Test (coverage) 与 dependabot 属 path-filter 跳过,按 AGENTS.md 算全绿)
   测试证据是真实输出	✅ 含 before/after 的 turbo 实跑 + 守卫的双向验证

   两处缺口都修了,而且 plugin-list 确实是同型故障

   我派发时扩的范围得到了独立复现验证:

   $ pnpm exec turbo run type-check --filter=@object-ui/plugin-list
     src/ListView.tsx(24,32): error TS2307: Cannot find module '@object-ui/permissions'
   

   plugin-list 只报一条(它只在一个文件里 import permissions),但是同一类失败,不是"依赖边本来就完整"。修复后 @object-ui/permissions:build 出现在任务图里 —— 那正是原先缺的那条边。

   关于 lockfile 那段 diff,值得说清楚

   diff 里两个包的 @object-ui/permissions 从 lockfile 的 dependencies 段移到了 devDependencies 段。这不是把依赖降级:pnpm 之前把这个 peer 自动装上并记在 importer 的 dependencies 下(所以路径能解析),但 turbo 读的是 package.json 而不是 lockfile,^build 只沿 dependencies/devDependencies 走 —— 这正是"能 import 却构建不到"的成因。两个包发布用的 dependencies / peerDependencies 一字未动,消费者零影响。

   守卫测试:采纳,且形态比我要求的好

   我在派发里把守卫列为"可选、你自己判断",它做了,而且做对了几处关键的地方:

   • 从 pnpm-workspace.yaml 读 globs,不硬编码目录 —— 新增 workspace 根当天就被覆盖;
   • 有反空转断言(expect(packages.length).toBeGreaterThan(30) + 点名两个包必须存在)—— 解析器坏掉或目录搬家时不会退化成"对空列表全绿";
   • 遇到不认识的 workspace glob 语法直接 throw 而不是跳过 —— 注释里写明理由:"一个悄悄停止检查一部分仓库的守卫比没有守卫更糟";
   • 没有豁免名单,理由是当前全仓已干净,而豁免项与本 bug 本身无法区分。

   双向验证也做了:删掉 devDep 行 → 守卫报出准确的违规包名与修法;恢复 → 绿。272ms,已挂在 pnpm test 的 unit project 下(scripts/**/*.test.ts 已被 glob 覆盖),不需要额外接工作流,也就没有"下次有人忘了接线"的风险。

   这把本单从"修一条依赖边"升级成了"这个不变量以后由机器守着",符合本单真正的诉求(scoped typecheck 的答案必须可信)。

   决策:changeset 不加(PM 裁定,可否决)

   开发 agent 把这条作为 open_questions 交上来了,我按升级门槛判定为不需要上升维护者,直接采纳 A:

   • 改动只有 devDependencies 与一个测试文件。npm 消费者从不安装依赖的 devDependencies,而 dependencies / peerDependencies 逐字节未变 —— 无任何消费者可观测的变化;
   • AGENTS.md 明确「纯 bug 修复不需要 changeset」,这比纯 bugfix 更靠仓内;
   • 本仓 fixed 组有 39 个包,加一条 changeset 会为一次构建图修复把 39 个包整体升版重发;
   • 仓库自己的门禁 Changeset Fixed Group Check 判绿,与该判断一致。

   按长远合理性轴:一条"对消费者什么都没变"的 changelog 条目会训练读者略读 changelog,而那恰恰是本单在抱怨的同一种失效 —— 你唯一需要信任的信号里混进了无关噪音。真正的持久保护是那条守卫测试,不是 changelog 条目。

   维护者若倾向 B,补一条 patch 是一分钟的跟进,门禁两种情况都绿。

   ---

   Generated by Claude Code
6. xuyushun441-sys

   closed this as completedin #3242on Aug 3, 2026
7. xuyushun441-sys commented on Aug 3, 2026

   

   xuyushun441-sys

   on Aug 3, 2026 – with Claude

   Contributor

   More actions

   更正一条我引用的证据(结论不变,但支撑变弱了)

   我在上面的验收里为"不加 changeset"列了这条依据:

   仓库自己的门禁 Changeset Fixed Group Check 判绿,与该判断一致。

   这条引用是错的,应当撤回。 #3212(PR #3253)在核对 ci.yml 时查明:changeset-check 这个 job 跑的是 scripts/check-changeset-fixed.mjs,它校验的是「每个 workspace 包都在 changeset fixed 组里或被显式忽略」——检查的是分组成员资格,根本不检查 PR 有没有加 changeset。

   也就是说它加不加 changeset 都会绿,所以它的绿色对"该不该加"这个问题零信息量,不能当作佐证。原单正文里"changeset-check 会因为缺 changeset 而拦 PR"那句话也是同一个误解,#3253 已按脚本实际行为改写文档。

   结论仍然不变

   不加 changeset 的真实依据是另外两条,它们不受影响:

   1. 改动只有 devDependencies 与一个测试文件,dependencies / peerDependencies 逐字节未变,npm 消费者从不安装依赖的 devDependencies —— 无任何消费者可观测的变化;
   2. AGENTS.md 明确「纯 bug 修复不需要 changeset」,而本仓 fixed 组有 39 个包,加一条会为一次构建图修复整体升版重发。

   维护者若倾向补一条 patch,仍然是一分钟的跟进。

   顺带一提:本仓真正管 changeset 政策的门禁是 changeset-guard.yml(在检查列表里显示为 Changeset Bump Policy),与 changeset-check 不是一回事 —— 这两个名字容易混,#3253 的工作流清单表新增了"显示名 ≠ 文件名"一列正是为了这个。

   ---

   Generated by Claude Code
8. akarma-synetal

   added a commit that references this issue on Aug 3, 2026

   fix(plugin-detail,plugin-list): add missing @object-ui/permissions de…

   ...

   This issue will close once commit 5dcec82 is merged into the 'main' branch.

   5dcec82