概述
内部库的破坏性变更若只发版本而不给迁移指引，会迫使各团队同时仓促升级。语义化版本并记录接口变化、为破坏性变更写迁移指南、以来源信息发布到私有仓库并公告与跟踪采用，可让升级有序可控。
关键步骤
- 语义化版本并记录对外接口变化。
- 为破坏性变更编写迁移指南。
- 带来源信息发布到私有仓库。
- 公告消费方并跟踪升级采用。
验证
- 已发布版本可从私有仓库安装。
- 消费方可依指南完成迁移。
- 破坏性变更均有迁移指引。
- 未升级团队有跟踪。
决策点
消费方升级缓慢时可先提供兼容垫片再做大版本；内部发布也应经 CI 带来源，内部并不意味着可以省略来源。
适用范围
本条目围绕「内部库发布工作流」给出可复制的步骤、验证方式与常见问题，适合需要按此流程落地的工程团队。执行时请结合自身上下文调整命令与阈值，并在变更前后留存证据，便于后续复核与回滚。
建议在正式环境落地前先在预发或隔离环境演练一遍，把关键观测指标与负责人一并记录，确保出现异常时能快速定位并恢复。
npm publish --registry https://npm.internal.example.com
# announce and track adoption in the internal channel