yarn.lock 你锁明白了吗？

字节前端

字节前端的技术实践分享 | 微信公众号：字节前端ByteFE

前言

你是否遇到过这种场景，项目拉下来后执行 yarn install 安装依赖，yarn.lock 却提示有变更，我明明什么都没做呢，这是为啥？但是基于以往的经验（出过 case），yarn.lock 不应该有 diff 才对，一定是哪里出了问题！但是 git diff yarn.lock 发现自己也看不明白（我好菜）

举个

还原一下我出过的 Case 项目里原本有个依赖 foo ：

package.json 里定义的 foo@^1.0.1
yarn.lock 里的版本是 1.0.1

同学 A 是负责 foo 这个库的开发，一次发版后，到项目里升级这个依赖到 1.1.0，但是提交代码时，只变更了 package.json，没有更新 yarn.lock

package.json foo@^1.0.1``foo@^1.1.0
yarn.lock 没变，还是 1.0.1

然后大家每次拉新代码并安装依赖后，本地总有个烦人的 yarn.lock 文件变更，大家心想应该是有人升级依赖的时候忘记提交 yarn.lock 了于是同学 B 行动了：

先看了下 foo 这个库现在有哪些版本，最新版本是 1.1.2 ，跟 package.json 里定义的 ^1.1.0 差了两个版本，不能保证线上是 1.1.0 ，因为每次上线，都会去找符合 ^1.1.0 这个 version range 里的最新版本
所以去看了下最后一次上线的构建日志，发现下载的是 1.1.2
于是提交了 yarn.lock，把版本锁在了 1.1.2

然后过了一天，拉群了

1.1.2 版本有 bug，修复后发布了 1.1.3
但是项目里，由于 B 把版本锁在了 1.1.2，锁住了 bug
同学 A 质问 B 为什么要锁别人的库的版本
这个 case 记了几个 TODO

因为没有提交 yarn.lock，不确定同学 A 是通过 yarn upgrade 升级的版本，还是手动去改了 package.json，所以——不要手动修改 package.json 升级版本
升级依赖后，一定要同时提交 package.json 和 yarn.lock

About yarn.lock

yarn.lock 的作用？

锁定唯一版本！

package.json 里定义的是版本区间，如 ^1.0.0
而 yarn.lock 里的 version 字段是唯一的版本号，如 1.0.0

yarn.lock 长啥样？

里面都是一块一块的，每一块大概长下面这样：

core-js-compat@^3.0.0:
  version "3.14.0"
  resolved "https://registry.npmjs.org/core-js-compat/-/core-js-compat-3.14.0.tgz#b574dabf29184681d5b16357bd33d104df3d29a5"
  integrity sha1-tXTavykYRoHVsWNXvTPRBN89KaU=
  dependencies:
    browserslist "^4.16.6"
    semver "7.0.0"

Identifier(s)

第一行的 core-js-compat@^3.0.0 是依赖的 identifier。和 package.json 里对应的包名和版本区间，用 @ 连接。这边的标题里带了 (s) ，是因为多个 Identifier 最终可能都指向同一个版本（具体例子可以看下文 ### dependencies 里给出的例子）

`version`

第二行 version 是实际安装的版本。通常是满足版本区间里的一个版本，比如上一行 identifier 里版本区间是 ^3.0.0 ，这里实际安装的是 3.14.0 ，符合要求。但是为什么要说是“通常”呢，因为有例外，在后文 ### resolutions 部分会讲到。

`resolved`

第三行 resolved 的是一个链接，是下载这个包的地址。这个 url 里的域名部分跟 项目里配置的 .npmrc 或 你本地的 npm 配置的 registry 有关。

`integrity`

第四行 integrity 是对 resolved 下载下来的文件进行完整性校验。如果出现 diff，说明同一个下载链接对应的文件被修改过。

`dependencies`

第五行 dependencies 是这个包自己的依赖。如这里依赖的 browserslist "^4.16.6" ，你想看下实际安装的哪个版本，就可以把它拼成 Identifier browserslist@^4.16.6" ，以此为关键字在 yarn.lock 中搜索，就能找到对应的“块”了。

browserslist@4.16.6, browserslist@^4.0.0, browserslist@^4.11.1, browserslist@^4.12.0, browserslist@^4.14.5, browserslist@^4.16.0, browserslist@^4.16.6, browserslist@^4.3.6, browserslist@^4.6.2, browserslist@^4.6.4, browserslist@^4.7.2, browserslist@^4.9.1:
  version "4.16.6"
  resolved "https://https://registry.npmjs.org/browserslist/-/browserslist-4.16.6.tgz#d7901277a5a88e554ed305b183ec9b0c08f66fa2"
  integrity sha1-15ASd6WojlVO0wWxg+ybDAj2b6I=
  dependencies:
    caniuse-lite "^1.0.30001219"
    colorette "^1.2.2"
    electron-to-chromium "^1.3.723"
    escalade "^3.1.1"
    node-releases "^1.1.71"

上面这个例子第一行有多个 Identifiers，最终都指向第二行的 version "4.16.6" ，可以检查下 4.16.6 版本满足上面所有 Identifiers 里的版本区间： 4.16.6 、 ^4.0.0 ...

yarn.lock 是如何生成的？

yarn.lock 是自动生成的， 你不应该去手动的修改 。

依赖管理

比如我们的常规操作，都会自动更新 package.json 和 yarn.lock

新增依赖： yarn add
升级依赖： yarn upgrade

霸道的 `resolutions`

假如你的项目依赖了 foo , foo 依赖了 bar@^1.0.0 。假设 bar 现在有两个版本 1.0.0 和 1.1.0 。很不幸， bar 在发布 1.1.0 的时候没有做好向后兼容。导致 foo 和 bar@1.1.0 不能搭配使用。如果你可以等：

要么等 foo 把依赖 bar 锁成 1.0.0 并重新发版
要么等 bar 修复兼容问题后重新发版

那如果你等不了呢，你已知 foo 和 bar@1.0.0 可以正常工作。如果你能锁住 foo 对 bar 的依赖就好了，但是这定义在 foo 的 packge.json 里，你总不能去改 node_modules/foo/package.json 吧？这不合适。 resolutions 可以解决你的问题，只要在你自己项目的 package.json 里定义：

"resolutions": {
  "foo/bar": "1.0.0"

这里的 key "foo/bar" 表示 foo 的 直接依赖 bar ，把版本区间重写成 1.0.0 。如果 foo 不是直接依赖的 bar （ foo -> ... -> bar ），我还需要把中间的链路都捋清楚吗？不用那么麻烦！

"resolutions": {
  "foo/**/bar": "1.0.0"

如果你的项目里有很多依赖直接/间接的依赖了 bar ，每个定义的版本区间可能有差别，你知道某个版本可以让他们都能正常工作，而不用安装多个版本。也可以不用声明前缀部分，只写包名 bar 。这样不管是哪里依赖到了 bar 都会指向你声明的哪个版本。

"resolutions": {

前言

举个

About yarn.lock

yarn.lock 的作用？

yarn.lock 长啥样？

Identifier(s)

version

resolved

integrity

dependencies