npm的package.json和package-lock.json更新策略

语义化版本

在一探package-lock.json究竟之前，你必须要理解semver。它是npm背后的小小功臣。你可以从这里了解到npm是如何使用它的。概括来讲，假若你在开发一个可供其它应用使用的应用（或者叫包依赖），你必须说明每次升级变更会对第三方使用产生哪些影响。这就是语义化版本想要传达的。一个版本有三部分：X, Y, Z，分别指代大版本，小版本，与查缺补漏版本。比如1.2.3，那么就是大版本1，小版本2，bugfix版本3。bugfix版本不会影响任何功能，小版本变更往往是增加新功能，也不会影响使用。而大版本变更往往会带来使用层面不兼容的情况，需要再做调整。（想想webpack每次升级的时候！）

NPM包管理

正是为了让包管理变简单，npm出现了。一个项目可能有上百个依赖，每个依赖又有上百个依赖。为了你不陷入依赖地狱，只需简单几行命令，npm就可以安装并管理这些依赖，大大节省了时间。

当你使用npm安装一个包(并保存它)的时候，package.json里就自动添加了一条信息，包括包名和其版本。npm当然也支持版本的通配符。npm默认安装最新版本，然后在其版本号之前添加一个^符号。比如^1.2.12，它表明最低应使用1.2.12版本，并且在这之上，拥有相同大版本号的任何版本都是OK的。毕竟小版本和bugfix版本不会对使用造成任何影响，所以用任何相同大版本的更高级版本都很安全。可以从这里了解semver通配符的更多信息，以及npm的semver计算器。

• 符号^：表示安装不低于该版本的应用，但是大版本号需相同，例如：vuex: "^3.1.3"，3.1.3及其以上的3.x.x都是满足的。
• 符号~：表示安装不低于该版本的应用，但是大版本号和小版本号需相同，例如：vuex: "^3.1.3"，3.1.3及其以上的3.1.x都是满足的。
• 无符号：无符号表示固定版本号，例如：vuex: "3.1.3"，此时一定是安装3.1.3版本。

为什么需要package-lock.json

npm install的输入是package.json，它的输出是一棵node_modules树。理想情况下，npm install应该像纯函数一样工作，对于同一个package.json总是生成完全相同的node_modules树。在某些情况下，确实如此。但在其他很多情况中，npm无法做到这一点。有以下原因：

• 不同版本的npm的安装算法不同。
• 某些依赖项自上次安装以来，可能已发布了新版本，因此将根据package.json中的semver-range version更新依赖。
• 某个依赖项的依赖项可能已发布新版本，即使您使用了固定依赖项说明符（是"1.2.3"而不是"^1.2.3"），它也会更新，因为你无法固定子依赖项的版本。

// package.json
"dependencies": {
    "packageA": "^2.1.0"
}

而依赖项版本更新可能会带来一些问题，例如：程序猿A新建了一个项目，生成了上面 ↑ 这份package.json文件，但程序猿A安装依赖的时间比较早，此时packageA的最新版本是2.1.0，该版本与代码兼容，没有出现bug。后来程序猿B克隆了程序猿A的项目，在安装依赖时packageA的最新版本是2.2.0，那么根据语义，npm会去安装2.2.0的版本，但2.2.0版本的API可能发生了改动，导致代码出现bug。

这就是package.json会带来的问题，同一份package.json在不同的时间和环境下安装会产生不同的结果

理论上这个问题是不应该出现的，因为npm作为开源世界的一部分，也遵循一个发布原则：相同大版本号下的新版本应该兼容旧版本。即2.1.0升级到2.2.0时API不应该发生变化。

但很多开源库的开发者并没有严格遵守这个发布原则，导致了上面的这个问题。

为了在不同的环境下生成相同的node_modules，npm使用package-lock.json。无论何时运行npm install，npm都会生成或更新package-lock.json。

不同npm版本下npm i的规则

• npm 5.0.x版本：不管package.json中依赖是否有更新，npm i都会根据package-lock.json下载。针对这种安装策略，有人提出了这个issue - #16866 ，然后就演变成了5.1.0版本后的规则。
• 5.1.0版本后：当package.json中的依赖项有新版本时，npm install会无视package-lock.json去下载新版本的依赖项并且更新package-lock.json。针对这种安装策略，又有人提出了一个issue - #17979，参考 npm 贡献者 iarna 的评论，得出5.4.2版本后的规则。
• 5.4.2版本后：
  • 如果只有一个package.json文件，运行npm i会根据它生成一个package-lock.json文件，这个文件相当于本次install的一个快照，它不仅记录了package.json指明的直接依赖的版本，也记录了间接依赖的版本。
  • 如果package.json的semver-range version和package-lock.json中版本兼容(package-lock.json版本在package.json指定的版本范围内)，即使此时package.json中有新的版本，执行npm i也还是会根据package-lock.json下载 ------ 示例参考下面实践场景一。
  • 如果手动修改了package.json的version ranges，且和package-lock.json中版本不兼容，那么执行npm i时package-lock.json将会更新到兼容package.json的版本 ------ 示例参考下面实践场景二。

注意：npm install读取package.json创建依赖项列表，并使用package-lock.json来通知要安装这些依赖项的哪个版本。如果某个依赖项在package.json中，但是不在package-lock.json中，运行npm install会将这个依赖项的确定版本更新到package-lock.json中，不会更新其它依赖项的版本。

实践

场景一

// package.json
"dependencies": {
	"vue": "^2.0.0"
}

// package-lock.json
"dependencies": {
	"vue": {
		"version": "2.1.0",
		"resolved": "https://registry.npm.taobao.org/vue/download/vue-2.1.0.tgz",
		"integrity": "sha1-KTuj76rKhGqmvL+sRc+FJMxZfj0="
	}
}

这种情况下package-lock.json指定的2.1.0在^2.0.0指定的范围内，npm install会安装vue2.1.0版本。

场景二

// package.json
"dependencies": {
	"vue": "^2.2.0"
}

// package-lock.json
"dependencies": {
	"vue": {
		"version": "2.1.0",
		"resolved": "https://registry.npm.taobao.org/vue/download/vue-2.1.0.tgz",
		"integrity": "sha1-KTuj76rKhGqmvL+sRc+FJMxZfj0="
	}
}

这种情况下package-lock.json指定的2.1.0不在^2.2.0指定的范围内，npm install会按照^2.2.0的规则去安装最新的2.6.10版本，并且将package-lock.json的版本更新为2.6.10。

关于npm源

最近开发中有一个新需求，需要使用 tim-js-sdk，使用 npm install tim-js-sdk -S 下载 tim-js-sdk 后，发现 package-lock.json 中有一个包的 resolved 字段变成了 registry.npmjs.org，具体说明如下 ：

• 首先查询本地的 npm 源：npm config get registry
  
• 然后下载 tim-js-sdk：npm install tim-js-sdk -S；package-lock.json 会更新。package-lock.json 部分前后对比图：左边是更新前的，我同事开发时安装的，右边是更新后的，主要的变化就是 resolved 字段从 11x.2x.1xx.6x:4873 变成了 registry.npmjs.org。
  
  node_modules 下 @babel/generator 的 package.json 部分截图：
  
  node_modules 下 @vant/weapp 的 package.json 部分截图：
  
• 结论：node_modules 下的每个包的 package.json 中指定了 _resolved 字段，当去更新 package-lock.json 时，会去 copy 这个字段，而不是当前 npm 指定的源。很有可能是在初始化项目、一开始执行 npm install 的时候的源是 registry.npmjs.org，后面即使你更新了源，也不会改变已经下载的包的 _resolved 字段。可以通过删掉整个 node_modules 重新下载解决这个问题，当然最好的方式是在项目根目录下创建一个 .npmrc 的文件，在其中指定 npm 源，以保证团队的成员使用的是统一的 npm 源，这样就不会在拉取代码的时候出现 package-lock.json 中有很多冲突的情况。

关于npm ci

介绍

• ci：Continuous Integration。
• npm 版本至少是 v5.7.1。
• 此命令与 npm install 类似，不同之处在于它旨在用于自动化环境，例如集成测试环境、线上环境、或者您希望确保干净安装依赖项的任何情况。通过跳过某些面向用户的功能，它可以比常规的 npm install 快得多。它也比常规安装更严格，它可以捕获由于本地环境的增量安装引起的错误或不一致。
• npm ci 是根据 package-lock.json 去安装确定的依赖，package.json 只是用来验证是不是有不匹配的版本，假设 package-lock.json 中存在一个确定版本的依赖 A，如果 package.json 中不存在依赖 A 或者依赖 A 版本和 lock 中不兼容，npm ci 就会报错。

npm ci 和 npm install 差异

• 项目必须存在 package-lock.json 或 npm-shrinkwrap.json。
• 如果 package-lock.json 中的依赖和 package.json 中不匹配，npm ci 会退出并且报错，而不是去更新 package-lock.json。
• npm ci 只能安装整个项目的依赖，无法安装单个依赖。
• 如果 node_modules 已经存在，它将在 npm ci 开始安装之前自动删除。
  npm ci 永远不会改变 package.json 和 package-lock.json。
• 缓存 npm ci --cache .npm
• npm ci 时建议加上 --quiet --no-progress 关闭进度和其他无用 log，否则产生的日志会很大。
• 所以 ci 时推荐完整的命令为 npm ci --cache .npm --quiet --no-progress

npm和cnpm的差异

• cnpm i不受package-lock.json影响，只会根据package.json进行下载。
• cnpm i xxx@xxx不会跟新到package-lock.json中去。
• npm i xxx@xxx会跟新到package-lock.json中去。
• 总结：所以在实际开发中不建议使用cnpm

参考

• npm、cnpm与package-lock.json的操作
• npm的lock机制解析
  
• npm install package-lock.json 的更新策略
• 关于你想知道的package-lock.json的一切