NPM官方新版本发布后，如何规范管理@beta、@next等dist-tag？

不需要每次发布新版本都手动执行npm dist-tag add mypkg@{latest} next，行业里有更清晰高效的@next标签管理惯例，核心是明确两个标签的定位：

• 预发布阶段绑定@next
  当你开发下一个大版本（比如v4.x）的预发布版时，发布时直接指定@next标签，比如：

  npm publish --tag next
  

  这样@next会自动指向该预发布版本（如v4.0.0-beta.1），无需事后手动调整。此时@latest仍停留在稳定的正式版（如v3.x），用户可根据需求选择安装mypkg@next尝新，或默认安装@latest获取稳定版。

• 正式发布后调整@next的指向逻辑
  当v4.0.0正式发布时，直接执行默认的npm publish即可，@latest会自动切换为v4.0.0。

  • 若接下来要开发v4.x的小版本预发布版（如v4.1.0-alpha.1），发布时依然用npm publish --tag next，让@next跟随新的预发布版本；
  • 若发布的是v4.x的稳定小版本（如v4.0.1），直接发布到@latest即可，此时@next可保留在之前的预发布版——毕竟@next的核心作用是提供下一个版本的预览/预发布内容，而非镜像@latest的稳定版。

• 核心定位原则

  • @latest：固定指向当前最稳定的正式版，是npm默认标签，用户无指定时安装的就是这个版本；
  • @next：主要用来承载下一个大版本的预发布版或最新开发预览版，不需要时刻和@latest保持同步。只有当你没有正在进行的预发布开发，且希望@next也提供最新稳定版时，才需要偶尔执行一次npm dist-tag add mypkg@latest next，但这不属于常规操作。

内容的提问来源于stack exchange，提问作者tga