Changesets 3.0 发布：对等依赖下游包默认升补丁版本，纯 ESM 发布，安装体积缩减 88%

Changesets 3.0 发布：对等依赖下游包默认升补丁版本，纯 ESM 发布，安装体积缩减 88% — infoq.cn · 7 小时前 · 🛠 工具 / 开源

Changesets 3.0 正式发布，这是这套面向 monorepo 的版本管理与变更日志工具自 2.x 以来幅度最大的一次破坏性升级，三项改动最受关注：以 peerDependencies 方式依赖某个包的下游包，在该依赖发布新版本后默认只提升补丁版本，而不再被连带推上大版本；整个工具链改为纯 ESM 发布，CommonJS 产物被彻底移除；官方给出的安装体积缩减幅度为 88%。前两项直接改写了长期困扰大型仓库的版本级联行为——过去底层包的一次改动会沿着 peer 依赖关系把成批上层包一起推成 major，语义化版本的信号因此失真，使用者被迫面对大量并无实质破坏的升级。改成补丁级默认后，维护者可以用配置显式声明哪些依赖关系需要触发更高层级的提升，把版本判断重新交还给人工。纯 ESM 与体积瘦身则是对分发形态的取舍，意味着仍以 require 加载这些包的旧构建管线需要先升级运行时或改用动态导入。Changesets 的常规工作流是开发者在提交时写入 changeset 文件记录改动意图，再由命令行在发版时批量计算版本号、生成 CHANGELOG 并发布，pnpm、Astro 等大量开源 monorepo 都在使用这套方案。作者的核心结论是：这次升级用一次性的迁移成本，换来更可控的版本语义与更轻的依赖树，长期看对生态的版本治理利大于弊。

核心信息

版本级联规则发生翻转：在 3.0 之前，若 A 包以 peerDependencies 依赖 B 包，B 包发布新版本时 A 包会跟随其变更级别一起升到 major；3.0 起默认只给 A 包一个补丁版本提升。这一默认值的调整直接压缩了 monorepo 中一次底层改动引发上百个包集体发布大版本的连锁反应，也让语义化版本号更贴近真实的破坏性变更，减少使用者被无意义 major 升级打断的频率。
纯 ESM 发布：3.0 移除了 CommonJS 入口，所有包仅提供 ESM 产物，条件导出与构建流程随之简化。代价是仍以 require 加载这些包的 Node 脚本或旧构建管线会直接失败，需要升级到支持 require(ESM) 的运行时，或改用 import()、打包器与测试工具的对应配置。只通过命令行使用 changeset 命令的团队受影响较小，以编程方式引入 @changesets 系列包的集成方则需要先做兼容性验证。
安装体积缩减 88%：官方称新版本的安装体积相比 2.x 减少约 88%，主要来自取消双格式产物、精简与内联依赖以及清理构建输出。这一指标衡量的是下载与安装阶段，对在 CI 中频繁执行安装的 monorepo 更为直接：缓存未命中时的冷启动安装会明显变快，容器镜像与依赖缓存占用的空间同步下降。需要注意的是它并不代表运行时性能提升，也不等同于构建耗时的降低。
迁移与配置：作为破坏性大版本，3.0 要求使用者检查配置与自定义脚本，尤其是 peer 依赖提升策略、CJS 互操作以及被内联依赖带来的路径变化。工具保留了通过配置覆盖默认行为的能力，维护者可以显式声明哪些依赖关系需要触发 minor 或 major 级别的提升。结合 JS 生态整体向 ESM 迁移的趋势，这次发版更像是一次把历史包袱一次性结清的时机，越早评估改动面，后续跟进成本越低。

💡 为什么值得读: 因为它是少数会直接改变你仓库里版本号语义的工具升级，读懂 peer 依赖默认降级与纯 ESM 这两步，就能判断自己的 monorepo 该立刻跟进还是先观望。

✍️ 小编看法: 版本号从来不只是数字，它是仓库之间最廉价也最容易被滥用的通信协议。Changesets 这次把 peer 依赖的下游默认降到补丁级，本质上是在承认一个事实：过去那种底层一动我就跟着 major 的机械规则，把语义化版本变成了噪音，消费者看到大版本号的第一反应从警惕变成了无视。但真正值得关注的是代价——补丁级默认同样会掩盖真实的破坏性变更。当某个 peer 依赖的最低版本被抬高，对使用宽松版本范围的消费者而言，装上新版本可能直接报错，而这在版本号上只体现为一次 patch。也就是说，规则把判断权交还给了维护者，却没有替他们做判断；能不能用好，取决于团队是否愿意在 changeset 里写清楚意图，而不是把它当成发版前的例行公事。88% 的体积缩减是个漂亮的数字，不过要留意它衡量的是下载与安装，而非运行性能或构建速度，真正的收益主要在 CI 冷启动与依赖缓存命中上，对本地开发体验的改善有限。纯 ESM 这一步更值得警惕：生态里仍有大量工具以 CommonJS 消费这些包，迁移期容易出现只能在打包器里跑通、在 Node 脚本里直接挂掉的情况。下一步值得观察两件事：一是有没有主流 monorepo 工具跟进类似的 peer 版本策略，把补丁级默认变成行业惯例；二是 require(ESM) 在 LTS 版本上的实际成熟度，能否把这次破坏性升级的痛感压到最低。如果你维护的是一个被广泛依赖的库，现在就该检查自己的 peer 范围声明是否过于宽松；如果你只是消费方，升级前先确认构建链路能不能吃下纯 ESM。

🏷️ Changesets, ESM, monorepo, package management