正文

一、语义化版本

格式遵循 X.Y.Z （主版本号.次版本号.修订号），且不含前导零。（更详细看这里）

X. 主要版本更新：表示一个破坏兼容性的大变化；

Y. 次要版本更新：表示不会破坏任何内容的新功能；

Z. 补丁版本更新：表示不会破坏任何内容的错误修复。

不遵循语义化版本的 npm 包，我们应该强烈谴责，并且不使用，你懂的。

二、npm 包管理

npm 是前端项目常用的包管理工具之一，使用者众多。一个简单的命令 npm install 就可以帮我们解决复杂的依赖问题。

例如，使用 npm install --save-dev eslint 然后就会在 package.json 生成一条记录 "eslint": "^6.7.1"。

关于 6.7.1 、~6.7.1 、^6.7.1 的说明：

6.7.1 表示只会安装 6.7.1 的版本。

~6.7.1 表示安装 6.7.x 的最新版本（不低于 6.7.1），但是不安装 6.8.x 及以上版本，也就是说安装时不改变大版本号和次要版本号。

^6.7.1：表示安装 6.7.1 及以上的版本，但是不安装 7.x.x，也就是说安装时不改变大版本号。

三、package-lock.json 的必要性

当我们使用 npm install 命令时，实际安装的 npm 包不一定是 package.json 上的版本号，可能是 6.8.x、6.9.x，因为以 npm 默认配置插入的记录是 ^6.7.1。

这样就会导致一个问题：每次安装的 npm 包版本可能都不一样，同时会带来一些风险。

比如：6.7.1 版本的包没问题，然后最新的 6.8.0 版本有 bug。此时我们一位新同事把项目拉取下来之后，使用 npm install 安装，然后自然会安装到 6.8.0 版本，这时候可能项目在新同事电脑就跑不起来了。这种情况是会影响到我们项目的稳定性的。（尤其是不遵循语义化控制的 npm 包，强烈谴责）

如何解决以上问题呢？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
"devDependencies": {
    "eslint": "^6.7.1"
}

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

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

理论上这个问题是不应该出现的，因为 npm 作为开源世界的一部分，也遵循一个发布原则：相同大版本号下的新版本应该兼容旧版本。即 6.7.1 升级到 6.8.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": {
    "eslint": "^6.7.1"
}
// package-lock.json
"eslint": {
    "version": "6.8.0",
    "resolved": "https://registry.npm.taobao.org/eslint/download/eslint-6.8.0.tgz?cache=0&sync_timestamp=1595098436203&other_urls=https%3A%2F%2Fregistry.npm.taobao.org%2Feslint%2Fdownload%2Feslint-6.8.0.tgz",
    "integrity": "sha1-YiYtZylzn5J1cjgkMC+yJ8jJP/s="
}

这种情况下 package-lock.json 指定的 6.8.0 在 ^6.7.1 指定的范围内，npm install 会安装 6.8.0 版本，且不会更新 package.json 和 package-lock.json 记录。

场景二

// package.json
"dependencies": {
    "eslint": "^6.8.0"
}
// package-lock.json
"eslint": {
    "version": "6.7.1",
    "resolved": "https://registry.npm.taobao.org/eslint/download/eslint-6.7.1.tgz?cache=0&sync_timestamp=1595098436203&other_urls=https%3A%2F%2Fregistry.npm.taobao.org%2Feslint%2Fdownload%2Feslint-6.7.1.tgz",
    "integrity": "sha1-JpzMzsPvYKsyNYpE0UesIJFUuRk="
}

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

五、关于 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 版本和 package-lock.json 中不兼容，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 和 cnpm 的差异

cnpm i 不受 package-lock.json 影响，只会根据 package.json 进行下载。
cnpm i xxx@xxx 不会跟新到 package-lock.json 中去。
npm i xxx@xxx 会跟新到 package-lock.json 中去。

package-lock.json 用处是？

正文