Repository navigation
objectui-range.mjs 默认仍按 feat|fix 类型过滤 —— 发布页 Console 段落同样会丢掉破坏性 refactor! #4843
Description
未认领。 刷 #4731(bump-objectui.sh 的 pin changeset 改成读 objectui 声明的 changeset)时发现的邻近问题,不在那条 PR 的范围内,另立。
现状
scripts/objectui-range.mjs —— docs/releases-maintenance.md 里「两个平台版本之间前端改了什么」的聚合层,产物直接贴进发布页的 Console 段落 —— 用的还是同一套类型猜测:
const KEEP = ALL_TYPES ? null : new Set(['feat', 'fix']);--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 的 pin changeset 只收 feat|fix 且静默截断到 40 条 —— 破坏性 refactor! 进不了前端发布记录 #4731 —— 同一失效模式,已在
bump-objectui.sh侧修好(PR fix(devx): objectui pin changeset comes from declared changesets, not commit types (#4731) #4842) - Release process: prevent frontend (objectui) changesets being missed when the console pin lags #3340 —— 两者共同要防的洞
Activity
xuyushun441-sys commentedon Aug 3, 2026
认领(PM 分派)
session_018iARDqtrhQgz6fVHDeDkbQclaude/issue-4843-objectui-range-read-changesetsdomain:devx(落点scripts/objectui-range.mjs)阻塞已解除:#4731 的 PR #4842 已于今日合入 main,
scripts/objectui-changeset-digest.mjs导出的collectAddedChangesets()/parseChangeset()现已可复用 —— 本单要的正是让两处收敛到同一个判据,而不是各写一份。Generated by Claude Code
xuyushun441-sys commentedon Aug 3, 2026
审核通过 — 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 唯一对外可见的契约改动。共享文件已压到最小:
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
fix(tooling): objectui-range reads objectui's declared changesets, no…
fix(scripts): release 页 Console 段改按破坏性判据分节,Breaking changes 不再结构性永不渲染 (…
fix(scripts): bound objectui-range --help's self-read to the header p…
fix(scripts): bound objectui-range --help's self-read to the header p…