Check Changeset 的失败文案把「空 changeset」推荐为出路 —— 而那正是 #4898 静默卡死发布的输入

[claude]

Check Changeset 闸门失败时的提示文案是:

::error::This PR adds no changeset. Run 'pnpm changeset' (an empty changeset is fine for
changes that release nothing), or apply the 'skip-changeset' label if it does not need one.

它把「空 changeset」与「skip-changeset 标签」当作等价的两条出路。在闸门自己的计数逻辑里它们确实等价(注释明写「An empty-frontmatter changeset still counts — it is the sanctioned "this PR releases nothing" declaration, on par with the skip-changeset label」),但在 changesets/action 眼里完全不等价:

• skip-changeset 标签 = 闸门层面的豁免,不产生任何输入;
• 空 frontmatter 的 changeset = 喂给 action 的真实输入,它会让分派逻辑落到 hasChangesets && !hasNonEmptyChangesets 那条 0 秒分支(All changesets are empty; not creating PR)。

而那条分支正是 #4898 的根因:版本号进了仓库、包没进注册表、Release run 全绿。17.0.0-rc.2 因此卡死。

为什么值得单独修

这条文案是主动的错误处方:它在开发者(或 agent)撞墙的那一刻,把一个已知会静默卡死发布的输入推荐给他。本次实测:PR #5290(修 #4900,即发布机器本身)的 Check Changeset 红了之后,PM 依据这条文案指示 dev「用空 changeset」——dev 拒绝并改用标签,理由正是 #4898。在一个专门修发布机器的 PR 里种一个空 changeset,后果会格外难查。

建议

改写提示文案,去掉「an empty changeset is fine」这个推荐,或至少把它降级为带警告的次选,并指向 #4898。同时值得检查 .changeset/ 目录里今天是否还残留空 frontmatter 的 md 文件(RC 模式下 changeset version 会保留已消费的 md,所以残留是可能的)。

若认为空 changeset 在某些场景下确实是正当声明,那就需要在闸门之外再加一道:禁止空 frontmatter 的 changeset 进入 .changeset/,让「声明」只走标签这一条路。

不指派 —— 归档,由维护者/相应车道裁定。

出处:#4900 / PR #5290 的验收过程(会话 session_015W6nhsDrz6zWQc8je12a1t)。相关:#4898、#4899、#4901。

---

Generated by Claude Code