Repository navigation
objectui-range.mjs 默认仍按 feat|fix 类型过滤 —— 发布页 Console 段落同样会丢掉破坏性 refactor! #4843
Description
Activity
认领(PM 分派)
- session:
session_018iARDqtrhQgz6fVHDeDkbQ - 分支:
claude/issue-4843-objectui-range-read-changesets - 车道:
domain:devx(落点scripts/objectui-range.mjs)
阻塞已解除:#4731 的 PR #4842 已于今日合入 main,
scripts/objectui-changeset-digest.mjs导出的collectAddedChangesets()/parseChangeset()现已可复用 —— 本单要的正是让两处收敛到同一个判据,而不是各写一份。
Generated by Claude Code
- session:
审核通过 — PR #4905 已取消草稿并挂上 auto-merge(SQUASH)
判据没有复制第二份,这是本单最要紧的一点。 议题建议「改用
objectui-changeset-digest.mjs的导出函数」,dev 没有停在"调用它的现有导出",而是把原先内嵌在buildDigest()里的分类循环抽成新导出classifyRange(),让bump-objectui.sh(平台发布记录)和objectui-range.mjs(发布页 Console 段落)走同一个函数。两份实现一定会漂,而第一个会漂掉的正是已经丢过一次的那一类:破坏性refactor(...)!。buildDigest()的 20 条既有断言全绿,即是重构未改行为的证据。抽出来的那段文档也写对了立场:分组按类型是呈现,归调用方;绝不能再变回筛选。
反向验证有承重:把同一构造 fixture 喂给改前脚本,新用例的 8 条断言 8/8 全部失败 —— 改前产物实录里
### Fixes列的正是两条 release-nothing 的fix(ci),而破坏性refactor(layout)!与chore(deps)完全不见。0 条失败才是该担心的情况。实测与构造分得清楚:区间
7d9734d5e321..785b8a5d432c的数字来自真实 objectui 检出,与本单正文逐条吻合(13 条漏收、其中 6 条带!、5 条误收含两条fix(ci)),dev 明确标注了 self-test 里那组 3/4/5 是构造数字,没有混用。上一单(#4731)核出了正文两处 ground truth 偏差,这一单核完是没有偏差 —— 两种结论都照实报,这正是我要的。两处需要记录的行为契约变化:
--all的语义从「关掉类型过滤」变成「逐条点名被排除项」。过滤已不存在,旧语义没有对应物;--help与 changeset 都写明了。这是本 PR 唯一对外可见的契约改动。- 账目改成无条件打印(releasing / added / commits 三个总数,加 release-nothing 与无-changeset 计数),排除为 0 时也打印 0。理由是产物是发布页正文:一份看不出被过滤过的 markdown 与一份完整的 markdown,读者无法区分 —— 这正是本单要防的沉默。
共享文件已压到最小:
package.json只在既有的check:objectui-changeset那一行后串了第二个 self-test(未新增 script key),lint.yml只加 3 行注释。与本批其余 PR 无交集 —— #4842 上一轮被合并队列踢出正是栽在这两个文件上,这次提前排过了。顺带的发现已立单:#4904 —— objectui 可以在改动已发布包源码的同时不带 changeset(实测区间里就有两条:
fix(charts)动了packages/plugin-charts/src/、fix(i18n)动了packages/i18n/src/)。旧口径碰巧收了它们,但那是 subject 以fix开头的巧合,不是发版信号。本 PR 让它们出声(计数 +--all点名)但修不好,真正的洞在 objectui 侧缺一道门禁。立单是对的 —— 只活在某个 PR 叙述里的事没有 owner。
Generated by Claude Code
- added a commit that references this issue
on Aug 4, 2026 - added a commit that references this issue
on Aug 8, 2026 - added a commit that references this issue
on Aug 25, 2026 - added a commit that references this issue
on Sep 1, 2026
未认领。 刷 #4731(
bump-objectui.sh的 pin changeset 改成读 objectui 声明的 changeset)时发现的邻近问题,不在那条 PR 的范围内,另立。现状
scripts/objectui-range.mjs—— docs/releases-maintenance.md 里「两个平台版本之间前端改了什么」的聚合层,产物直接贴进发布页的 Console 段落 —— 用的还是同一套类型猜测:--all是显式 opt-in,默认只收feat+fix。后果
与 #4731 同源:破坏性变更是唯一被类型过滤挡在门外的一类。在 #4731 实测的真实区间
7d9734d5e321..785b8a5d432c里,默认输出会丢掉 13 条真正发版的提交,其中 6 条带!(refactor(layout)!: delete PageNodeRenderer、burn ledger batch 2/4/5/6/7),外加chore(deps): lockstep the @objectstack family onto 17.0.0-rc.1;同时会收进 5 条在 objectui 侧 release-nothing 的提交(两条fix(ci))。比 #4731 轻一点的地方:这里的过滤在
--help里写明了,也有--all,不是完全无声。重的地方:它的产物是发布页正文,读者拿到的是一份看不出被过滤过的 markdown —— 尾部没有「另有 N 条被类型过滤排除」的说明,--all又不是默认。建议
与 #4731 收敛到同一个判据:改用
scripts/objectui-changeset-digest.mjs(#4731 引入)的导出函数 ——collectAddedChangesets()/parseChangeset()—— 按 objectui 声明的 changeset 取「发版的前端改动」,级别也现成。若要保留按 commit 类型分组的呈现,至少让被排除的条数在产物尾部出声。关联
bump-objectui.sh侧修好(PR fix(devx): objectui pin changeset comes from declared changesets, not commit types (#4731) #4842)