一文读懂 NPM 版本

版本号组成

node package 版本号由四部分组成：major.minor.patch[-prerelease]，比如：1.0.2-beta.1，其中 prerelease 可选。

• major：代表主版本号，通常在需要提交不能向下兼容的情况下对该版本号进行升级
• minor：代表次版本号，通常在新增功能时才对该版本号进行升级
• patch：代表修复版本号，升级该版本号通常代表修复一些bug，但没有新增功能或者存在不向下兼容的功能
• prerelease：带有该版本号的包通常表示在测试阶段，尚未稳定，通常不建议用户安装。

prerelease 说明: alpha、beta、rc

• alpha: 代表内部测试版，会有很多Bug，是比beta更早的版本，一般不建议对外发布
• beta: 相对alpha版本已有了很大的改进，但还是存在一些缺陷，需要经过多次测试来进一步消除
• rc：Release Candidate顾名思义就是正式发布的候选版本。和Beta版最大的差别在于Beta阶段会一直加入新的功能，但是到了RC版本，几乎就不会加入新的功能了，而主要着重于除错! RC版本是最终发放给用户的最接近正式版的版本，发行后改正bug就是正式版了，就是正式版之前的最后一个测试版

版本发布最佳实践

为了帮助依赖您的代码的开发人员，我们建议您从 1.0.0 开始您的包版本并按如下方式递增

major：代表主版本号，通常在需要提交不能向下兼容的情况下对该版本号进行升级
minor：代表次版本号，通常在新增功能时才对该版本号进行升级
patch：代表修复版本号，升级该版本号通常代表修复一些bug，但没有新增功能或者存在不向下兼容的功能
prerelease：带有该版本号的包通常表示在测试阶段，尚未稳定，通常不建议用户安装。

代码状态	阶段	规则	示例版本
首次发布	新产品	从 1.0.0 开始	1.0.0
向后兼容的缺陷修复	补丁版本	增加第三个数字	1.0.1
向后兼容的新功能	次要版本	增加中间数字并将最后一位重置为零	1.1.0
破坏向后兼容性的更改	要版本	增加第一位数字并将中间和最后一位数字重置为零	2.0.0

安装 NPM 时的版本控制

我们经常看到，在 package.json 中各种依赖的不同写法：

"dependencies": {
  "signale": "1.4.0",
  "figlet": "*",
  "react": "16.x",
  "table": "~5.4.6",
  "yargs": "^14.0.0"
}

前三个容易理解：

• "signale": "1.4.0"：固定版本号
• "figlet": "*"：任意版本号（即 >=0.0.0）
• "react": "16.x"：匹配主要版本（>=16.0.0 < 17.0.0）
• "react": "16.3.x"：匹配主要版本和次要版本（>=16.3.0 <16.4.0）

再看看后面两个，版本号包含 ~ 和 ^ 符号：

• ~：当安装依赖时获取到有最新版本时，安装到 x.y.z 中 z 的最新版本。即保持主版本号、次版本号不变的情况下，保持修订号的最新版本
• ^：当安装依赖时获取到由最新版本时，安装到 x.y.z 中 y 和 z 都为最新版本。即保持主版本号不变的情况下，保持次版本号、修订版本号为最新版本。

• 当主版本号为 0 的情况，会被认为是一个不稳定版本，情况与上面不同：

  • 主版本号和次版本号都为 0: ^0.0.z、~0.0.z 都被当作固定版本，安装依赖时均不会发生变化。
  • 主版本号为 0: ^0.y.z 表现和 ~0.y.z 相同，只保持修订号为最新版本。

除此以外，还包含以下规则：

• >：接受高于指定版本的任何版本
• >=：接受等于或高于指定版本的任何版本
• <=：接受等于或低于指定版本的任何版本
• <：接受低于指定版本的任何版本
• =：接受确切的版本
• -：接受一定范围的版本，例如 2.1.0 - 2.6.2
• ||：组合集合，例如 < 2.1 || > 2.6
• 可以合并其中一些符号，例如 1.0.0 || >= 1.1.0 < 1.2.0 即使用 1.0.0 或从 1.1.0 开始但低于 1.2.0 的版本。

使用 npm 安装

npm install

分5个阶段执行：

1. 读取 package.json 文件里声明的项目所需的包和版本
2. 分析 package.json 依赖关系
3. 下载 npm 包和依赖项。
4. 安装 npm 包和依赖项。

5. 把 npm 包和依赖项的变化写进 package-lock.json

   npm ci

   分6个阶段执行：

6. 检查 package-lock.json文件，如果不存在则退出
7. 删除 node_modules 文件夹 （相当于删除已经安装的 npm 包）
8. 读取 package-lock.json 以确定项目特定的包版本和依赖项
9. 安装这些特定版本的 npm 和依赖项
10. 通过对比 package-lock.json 验证安装的完整性
11. 不更新 package-lock.json。
    注意事项：
12. 仅当 package-lock.json 或者 npm-shrinkwrap.json 存在于工作目录中时，该命令才能正常执行；如果该 package-lock 文件丢失，命令无法执行
13. package-lock.json 或 npm-shrinkwrap.json 中声明的安装包应该也存在于 package.json 文件声明里，否则它将退出。

npm install vs npm ci

1. npm install 会在你允许的版本里安装最新的版本，例如 package.json 文件声明的依赖包A版本 ^1.1.2，当 A存在 1.2.0 时，实际会安装 1.2.0； 而 npm ci 则会严格按照 package-lock.json 里声明的版本进行版本安装
2. 所以 npm ci不更新 package-lock.json，而 npm install 则可能会更新 package-lock.json
3. npm ci 在进行安装时会删除 node_modules 的内容，而npm install则不会

总之，npm ci 能严格按照声明版本进行安装，是一种比较安全的安装方式。

总结

本文内容讲了 NPM的版本介绍、版本发布、版本安装和使用 npm 工具安装 NPM 的知识。后续我们会讲到其他版本管理（如 Yarn、Pnpm）工具安装 npm 的内容以及它们之间的联系和对比～

参考

• https://github.com/canvasT/blog/issues/2
• https://tsejx.github.io/node-guidebook/overview/ecology/npm-v...
• https://nodejs.cn/npm/packages-and-modules/contributing-packa...