package-lock.json 用处是?

2020-08-04  本文已影响0人  越前君

一、语义化版本

格式遵循 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.x6.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 无法做到这一点。有以下原因:

// 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_modulesnpm 使用 package-lock.json。无论何时运行 npm installnpm 都会生成或更新 package-lock.json

四、不同 npm 版本下 npm i 的规则

注意: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

介绍
npm ci 和 npm install 差异
npm 和 cnpm 的差异

参考

  1. package-lock.json 的作用

  2. npm、cnpm 与 package-lock.json 的操作

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

上一篇 下一篇

猜你喜欢

热点阅读