一次血的教训 记npm package-lock.json导致的腥风血雨

小结：

1、

场景在项目中升级了react17到18，页面antd-select框点击异常：页面卡顿、内存飙升、页面崩溃。

node_modules、package.json，重新构建

 

一次血的教训 记npm package-lock.json导致的腥风血雨_追逐、的博客-CSDN博客_package-lock.json删除了怎么办 https://blog.csdn.net/qq_29722281/article/details/108517149

一、问题产生
一次偶然的机会，发现公司代码仓库中，sdk构建和reactjs构建仓库中居然有package-lock.json，这两个本该在编译时生成的文件，对于有强迫症的我，自然看不下去。于是果断一个MR,删除了这两个package-lock.json。以为自己做了好事的我还在沾沾自喜，殊不知这给我带来了2天苦逼的问题定位…

二、过程&解决
MR合入的当日，21.0主分支base仓构建失败，CIE大佬找到我，跟我说是前端base仓构建的问题，我心中一惊，立即翻看当天合入的MR，发现能影响构建的流程的只有我的那个删除package-lock.json的MR。先定下心，看一下给的报错日志：

npm ERR! Unexpected end of JSON input while parsing near '...l.com"}],"directories'

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/louyanping/.npm/_logs/2018-12-14T03_32_00_994Z-debug.log
louyanpingdeMacBook-Pro:cnpc_group_buying louyanping$

1
2
3
4
5
6
没错，没有其他任何报错信息，就只有这模糊的一句话。当时流水线紧急，没考虑详细，直接新建一个分支，恢复删除的package-lock.json。想想先保证构建流程，再考虑问题。
上库之后，出乎意料的是，还是出现了上述的报错信息。这时候我就意识到问题的严重性了。

前两天听CIE负责人说机器环境可能变动，为了排除打包机器环境变动的原因导致，通过mr上库时间，找出最后一次构建成功的Base仓，回归到该提交，并提交到一个新的分支进行构建。发现可以成功构建，这就排除了机器环境的问题。

结合CIE 前一天的构建流水线正常，上完库就出问题这一点来看，问题基本可以定位是有代码上库导致，再次检查了一下当天上库的MR,再次确认只有我改动了构建相关的流程后，确定了是我上库删除package-lock.json的原因。
那么现在问题来了。我上库的代码导致了问题，还原后也不行，问题可能出在哪里？

缓存，这是我脑海中第一个闪过去的词。我后面提交的package-lock.json，已经无法还原由于缺失package-lock.json的期间，构建流程中某些缓存的东西，换句话说，由于没有package-lock.json，构建机器在安装依赖包的时候，做了一些非常规流程，更新了之前缓存包中依赖包。于是想到解决方案，清除npm缓存。

在构建机器执行 npm cache clean --force ，清除之前下载的包缓存，重新编译，发现之前的错没有了，但是取而代之的是另外一个错。

03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:5:45
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:9:18
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:10:18
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:11:18
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:12:22
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/process.d.ts[39m:8:27
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/util.d.ts[39m:6:56
03:06:13 TS2304: [31mCannot find name 'BigInt64Array'.[39m
03:06:13
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
证明我的想法是正确的！缓存导致了构建流程依赖包安装策略的变化，清除缓存后，依赖包安装策略变化，采用package.json中最新规定下载的包，但现在最新下载的包中的某些库和缓存中的库冲突了，导致了报错！

根据报错信息，定位到是jssdk中某个其他模块引用了TypeScript中的bigint新特性，直觉告诉我，这肯定是由于版本不兼容导致的。目前package.json中TypeScript中的版本为3.0.2，于是果断上TypeScript官网，查找更新记录，发现bigint的特性是在3.2版本后才支持。于是升级TypeScript中的版本为3.8.3，再次构建，问题终于得到解决。

三、总结
提交上库MR后，长舒一口气。这件事情到这里是暂时解决了，但是提交了package-lock.json导致的问题居然这么严重，不禁令人背脊发凉。回顾一下整个问题的产生，过程如下：

2020.01.21日 某个开发提交了package-lock.json 且该文件至今还没有其他提交
在这8个月的时间内，前端依赖库大大小小更新了好几拨
其实我们这段时间的构建，用的都是package-lock.json中指定的依赖缓存路径，即使我们升级了某些库的版本，用的还是缓存中的依赖路径，服务器并没有重新下载。比如这个例子中的‘某个库’，例如叫libA,在2020年1月的时候，是1.0.0版本，只需要typeScript 3.0.2既可以满足需求。但是在5月的时候，他升级了，变成了1.2.0，必须要typescript3.2.0，支持bigint的库才可以跑。然而由于库上存在package-lock.json，下载的库还是缓存中的1.0.0，在存在package-lock.json文件的情况下，构建流程不会有问题，因为大家都没变，所以库上的依赖根本没有更新!这无非是埋下了一颗定时炸弹，等着某个人去踩…
那个人就是我。从我删掉了库上的package-lock.json之后，恶魔的闸门被打开，依赖不兼容的问题显现…
这事情告诉我们，package-lock.json维护的重要性。在查阅了相关资料后发现，其实package-lock.json是推荐上库的，可怕的咱们上库了，后续的版本升级，却没有同步提交package.lock.json。导致了依赖不兼容。
 

 

npm/yarn lock真香 - SegmentFault 思否 https://segmentfault.com/a/1190000039684460

前言

看完本文，你将从整体了解依赖版本锁定原理，package-lock.json 或 yarn.lock 的重要性。首先要从最近接连出现两起有关 npm 安装 package.json 中依赖包，由于依赖包版本更新 bug 造成项目出错问题说起。

事件一：新版本依赖包本身 bug

项目本地打包正常，但是线上使用 Jenkins 完成 DevOps 交付流水线打包出错问题。报出如下错误：

**17:15:32**  ERROR in ./node_modules/clipboard/dist/clipboard.js
**17:15:32**  Module build failed (from ./node_modules/babel-loader/lib/index.js):
**17:15:32**  Error: Couldn't find preset "@babel/env" relative to directory "/app/workspace/SIT/node_modules/clipboard"

显示错误原因是 clipboard 插件没有安装 @babel/env 预设（preset）。明显这个是插件问题了，去官方库 clipboard 查看源码发现该库依赖包很少，大部分是原生实现。再看 issue 别人有没有出现同样的问题，目前来看还没有人提出。以此推断可能是插件本身的 "问题" 了。

但是我本地项目打包正常，线上的出错，可能由于本地版本和线上版本不一致导致（某个小版本出现的 bug）的。通过查看package.json 配置的 clipboard: "^2.0.4"，线上实际安装版本是 2.0.7，而我本地实际安装版本是 2.0.6
因此定位到 2.0.7 出现的 “问题”。

由于是插件本身“问题”，我的临时解决办法是锁定到 2.0.4 版本，也就是 clipboard: "2.0.4"，后面加上 package-lock.json。

打破沙锅问到底
既然“问题”已经定位到了 2.0.7 版本，进一步通过对比此次版本提交文件内容差异，发现 .babelrc 文件用到的 preset 是 env。

2.0.7 版本用的是 @bable/env，将 babel 更新到了 7！

问题基本定位到了，这里就顺便给作者提了一个 issues。

事件二：依赖包的新版插件 bug

一直正常使用的 braft-editor 优秀的富文本编辑器插件，最近在其他小伙伴电脑或者在我本地电脑重新部署项目，启动后发现 toHtml() 方法获取富文本 html 内容总是空！

历史版本是正常的，猜测可能又是版本更新造成。同样的，去官方库 braft-editor看看 issues 别人有没有遇到同样的问题。果然这次有，原因是它的依赖包 draft-js 更新后的问题，具体的看这个 issues。

这个是由于插件的依赖包更新出现的问题，直接去锁定当前插件没有作用，不会对它的依赖包产生约束（依赖包还是会去下载最新版本的包）。我的临时解决办法是尝试将版本回退到后一个版本并锁定。这样做的原因是回退版本的依赖包版本肯定会低于现在的，之前的版本是正常的。

经验教训

其实这两起事件是同一个诱因导致的：没有锁定当前项目依赖树模块的版本。下面就来探究一下依赖包的版本管理。

语义化版本（semver）

package.json 在前端工程化中主要用来记录依赖包名称、版本、运行指令等信息字段。其中，dependencies 字段指定了项目运行所依赖的模块，devDependencies 指定项目开发所需要的模块。
它们都指向一个对象。该对象的各个成员，分别由模块名和对应的版本要求组成，表示依赖的模块及其版本范围。对应的版本可以加上各种限定，主要有以下几种：

• 指定版本：比如 1.2.2 ，遵循“大版本.次要版本.小版本”的格式规定，安装时只安装指定版本。
• 波浪号（tilde）+指定版本：比如 ~1.2.2 ，表示安装 1.2.x 的最新版本（不低于1.2.2），但是不安装 1.3.x，也就是说安装时不改变大版本号和次要版本号。
• 插入号（caret）+指定版本：比如 ˆ1.2.2，表示安装 1.x.x 的最新版本（不低于 1.2.2），但是不安装 2.x.x，也就是说安装时不改变大版本号。需要注意的是，如果大版本号为 0，则插入号的行为与波浪号相同，这是因为此时处于开发阶段，即使是次要版本号变动，也可能带来程序的不兼容。
• latest：安装最新版本。

当我们使用比如 npm install package -save 安装一个依赖包时，版本是插入号形式。这样每次重新安装依赖包 npm install 时”次要版本“和“小版本”是会拉取最新的。一般的，主版本不变的情况下，不会带来核心功能变动，API 应该兼容旧版，但是这在开源的世界里很难控制，尤其在复杂项目的众多依赖包中难免会引入一些意想不到的 bug。

npm-shrinkwrap && package-lock

npm-shrinkwrap

正是存在这每次重新安装，依赖树模块版本存在的不确定性，才有了相应的锁定版本机制。

npm5 之前可以通过 npmshrinkwrap 实现。通过运行 npm shrinkwrap，会在当前目录下生成一个 npm-shrinkwrap.json 文件，它是 package.json 中列出的每个依赖项的大型列表，应安装的特定版本，模块的位置（URI），验证模块完整性的哈希，它需要的包列表，以及依赖项列表。运行 npm install 的时候会优先使用 npm-shrinkwrap.json 进行安装，没有则使用 package.json 进行安装。

package-lock

在 npm5 版本后，当我们运行 npm intall 发现会生成一个新文件 package-lock.json，内容跟上面提到的 npm-shrinkwrap.json 基本一样。

"vue-loader": {
  "version": "14.2.4",
  "resolved": "https://registry.npmjs.org/vue-loader/-/vue-loader-14.2.4.tgz",
  "integrity": "sha512-bub2/rcTMJ3etEbbeehdH2Em3G2F5vZIjMK7ZUePj5UtgmZSTtOX1xVVawDpDsy021s3vQpO6VpWJ3z3nO8dDw==",
  "dev": true,
  "requires": {
    "consolidate": "^0.14.0",
    "hash-sum": "^1.0.2",
    "loader-utils": "^1.1.0",
    "lru-cache": "^4.1.1",
    "postcss": "^6.0.8",
    "postcss-load-config": "^1.1.0",
    "postcss-selector-parser": "^2.0.0",
    "prettier": "^1.16.0",
    "resolve": "^1.4.0",
    "source-map": "^0.6.1",
    "vue-hot-reload-api": "^2.2.0",
    "vue-style-loader": "^4.0.1",
    "vue-template-es2015-compiler": "^1.6.0"
  },
  "dependencies": {
    "postcss-load-config": {
      "version": "1.2.0",
      "resolved": "https://registry.npmjs.org/postcss-load-config/-/postcss-load-config-1.2.0.tgz",
      "integrity": "sha1-U56a/J3chiASHr+djDZz4M5Q0oo=",
      "dev": true,
      "requires": {
        "cosmiconfig": "^2.1.0",
        "object-assign": "^4.1.0",
        "postcss-load-options": "^1.2.0",
        "postcss-load-plugins": "^2.3.0"
      }
    },
  }
},

当项目中已有 package-lock.json 文件，在安装项目依赖时，将以该文件为主进行解析安装指定版本依赖包，而不是使用 package.json 来解析和安装模块。因为 package-lock 为每个模块及其每个依赖项指定了版本，位置和完整性哈希，所以它每次创建的安装都是相同的。 无论你使用什么设备，或者将来安装它都无关紧要，每次都应该给你相同的结果。

npm5 版本下 install 规则

npm 并不是一开始就是按照现有这种规则制定的。

5.0.x 版本：

不管 package.json 中依赖是否有更新，npm install 都会根据 package-lock.json 下载。针对这种安装策略，有人提出了这个 issue ，然后就演变成了 5.1.0 版本后的规则。

5.1.0 版本后：

当 package.json 中的依赖项有新版本时，npm install 会无视 package-lock.json 去下载新版本的依赖项并且更新 package-lock.json。针对这种安装策略，又有人提出了一个 issue 参考 npm 贡献者 iarna的评论，得出 5.4.2 版本后的规则。

5.4.2 版本后：

如果只有一个 package.json 文件，运行 npm install 会根据它生成一个 package-lock.json 文件，这个文件相当于本次 install 的一个快照，它不仅记录了 package.json 指明的直接依赖的版本，也记录了间接依赖的版本。

如果 package.json 的 semver-range version 和 package-lock.json 中版本兼容(package-lock.json 版本在 package.json 指定的版本范围内)，即使此时 package.json 中有新的版本，执行 npm install 也还是会根据 package-lock.json 下载。

如果手动修改了 package.json 的 version ranges，且和 package-lock.json 中版本不兼容，那么执行 npm install 时 package-lock.json 将会更新到兼容 package.json 的版本。

yarn

yarn 的出现主要目标是解决上面描述的由于语义版本控制而导致的 npm 安装的不确定性问题。虽然可以使用 npm shrinkwrap 来实现可预测的依赖关系树，但它并不是默认选项，而是取决于所有的开发人员知道并且启用这个选项。
yarn 采取了不同的做法。每个 yarn 安装都会生成一个类似于npm-shrinkwrap.json 的 yarn.lock 文件，而且它是默认创建的。除了常规信息之外，yarn.lock 文件还包含要安装的内容的校验和，以确保使用的库的版本相同。

yarn 的主要优化

yarn 的出现主要做了如下优化：

• 并行安装：无论 npm 还是 yarn 在执行包的安装时，都会执行一系列任务。npm 是按照队列执行每个 package，也就是说必须要等到当前 package 安装完成之后，才能继续后面的安装。而 yarn 是同步执行所有任务，提高了性能。
• 离线模式：如果之前已经安装过一个软件包，用 yarn 再次安装时之间从缓存中获取，就不用像 npm那样再从网络下载了。
• 安装版本统一：为了防止拉取到不同的版本，yarn 有一个锁定文件 (lock file) 记录了被确切安装上的模块的版本号。每次只要新增了一个模块，yarn 就会创建（或更新）yarn.lock 这个文件。这么做就保证了，每一次拉取同一个项目依赖时，使用的都是一样的模块版本。
• 更好的语义化： yarn 改变了一些 npm 命令的名称，比如 yarn add/remove，比 npm 原本的 install/uninstall 要更清晰。

安装依赖树流程

1. 执行工程自身 preinstall。
   当前 npm 工程如果定义了 preinstall 钩子此时会被执行。
2. 确定首层依赖。
   模块首先需要做的是确定工程中的首层依赖，也就是 dependencies 和 devDependencies 属性中直接指定的模块（假设此时没有添加 npm install 参数）。工程本身是整棵依赖树的根节点，每个首层依赖模块都是根节点下面的一棵子树，npm 会开启多进程从每个首层依赖模块开始逐步寻找更深层级的节点。

3. 获取模块。
   获取模块是一个递归的过程，分为以下几步：

   • 获取模块信息。在下载一个模块之前，首先要确定其版本，这是因为 package.json 中往往是 semantic version（semver，语义化版本）。此时如果版本描述文件（npm-shrinkwrap.json 或 package-lock.json）中有该模块信息直接拿即可，如果没有则从仓库获取。如 package.json 中某个包的版本是 ^1.1.0，npm 就会去仓库中获取符合 1.x.x 形式的最新版本。
   • 获取模块实体。上一步会获取到模块的压缩包地址（resolved 字段），npm 会用此地址检查本地缓存，缓存中有就直接拿，如果没有则从仓库下载。
   • 查找该模块依赖，如果有依赖则回到第 1 步，如果没有则停止。
4. 模块扁平化（dedupe）。
   上一步获取到的是一棵完整的依赖树，其中可能包含大量重复模块。比如 A 模块依赖于 loadsh，B模块同样依赖于 lodash。在 npm3 以前会严格按照依赖树的结构进行安装，因此会造成模块冗余。yarn 和从 npm5 开始默认加入了一个 dedupe 的过程。它会遍历所有节点，逐个将模块放在根节点下面，也就是 node-modules 的第一层。当发现有重复模块时，则将其丢弃。这里需要对重复模块进行一个定义，它指的是模块名相同且 semver 兼容。每个 semver 都对应一段版本允许范围，如果两个模块的版本允许范围存在交集，那么就可以得到一个兼容版本，而不必版本号完全一致，这可以使更多冗余模块在 dedupe 过程中被去掉。
5. 安装模块。
   这一步将会更新工程中的 node_modules，并执行模块中的生命周期函数（按照 preinstall、install、postinstall 的顺序）。
6. 执行工程自身生命周期。
   当前 npm 工程如果定义了钩子此时会被执行（按照 install、postinstall、prepublish、prepare 的顺序）。

举例说明

插件 htmlparser2@^3.10.1 和 dom-serializer@^0.2.2 都有使用了 entities 依赖包，不过使用的版本不同，同时我们自己安装一个版本的 entities 包。具体如下：

--htmlparser2@^3.10.1
  |--entities@^1.1.1

--dom-serializer@^0.2.2
  |--entities@^2.0.0

--entities@^2.1.0

通过 npm install 安装后，生成的 package-lock.json 文件内容和它的 node_modules 目录结构：

可以发现：

1. dom-serializer@^0.2.2 的依赖包 entities@^2.0.0 和我们自己安装的 entities@^2.1.0 被实际安装成 entities@^2.2.0，并放在 node_modules 的第一层。因为这两个版本的semver 范围相同，又先被遍历，所有会被合并安装在第一层；
2. htmlparser2@^3.10.1 的依赖包 entities@^1.1.1 被实际安放在 dom-serializer 包的 node_modules中，并且和 package-lock.json 描述结构保持一致。

通过 yarn 安装后，生成的 yarn.lock 文件内容和它的 node_modules 目录结构：

可以发现与 npm install 不同的是：

1. yarn.lock 中所有依赖描述都是扁平化的，即没有依赖描述的嵌套关系；
2. 在 yarn.lock 中， 相同名称版本号不同的依赖包，如果 semver 范围相同会被合并，否则，会存在多个版本描述。

注意 cnpm 不支持 package-lock

使用 cnpm install 时候，并不会生成 package-lock.json 文件。cnpm install 的时候，就算你项目中有 package-lock.json 文件，cnpm 也不会识别，仍会根据 package.json 来安装。所以这就是为什么之前你用 npm 安装产生了 package-lock.json，后面的人用 cnpm 来安装，可能会跟你安装的依赖包不一致。

因此，尽量不要直接使用 cnpm install 安装项目依赖包。但是为了解决直接使用 npm install 速度慢的问题，可以设置 npm 代理解决。

// 设置淘宝镜像代理
npm config set registry https://registry.npm.taobao.org

// 查看已设置代理
npm config get registry

当然，也可以通过 nrm 工具，快捷操作设置代理。

全局安装

$ npm install -g nrm

查看已安装代理列表

$ nrm ls

* npm -----  https://registry.npmjs.org/
  yarn ----- https://registry.yarnpkg.com
  cnpm ----  http://r.cnpmjs.org/
  taobao --  https://registry.npm.taobao.org/
  nj ------  https://registry.nodejitsu.com/
  skimdb -- https://skimdb.npmjs.com/registry

切换代理

$ nrm use cnpm  //switch registry to cnpm

* Registry has been set to: http://r.cnpmjs.org/

测速

nrm test cnpm

* cnpm --- 618ms

然而，设置这些全局代理可能还是不能满足下载一些特定依赖包（在没有 VPN 情况下），比如：node-sass、puppeteer、chromedriver、electron 等。可以通过 .npmrc 文件设置具体依赖包的国内镜像。该文件在项目 npm install 时会被加载读取，优先级高于 npm 全局设置。

registry=https://registry.npm.taobao.org/
sass_binary_site=http://npm.taobao.org/mirrors/node-sass
chromedriver_cdnurl=http://npm.taobao.org/mirrors/chromedriver
electron_mirror=http://npm.taobao.org/mirrors/electron/
puppeteer_download_host=http://npm.taobao.org/mirrors/chromium-browser-snapshots/

总结

项目在以后重新构建，由于依赖树中有版本更新，造成意外事故是不可避免的，究其原因是整个依赖树版本没有锁死。解决方案分为如下四种：

• package.json 中固定版本。注意：仅能锁定当前依赖包版本，不能控制整棵依赖树版本。
• npm+npm-shrinkwrap.json。
• npm+package-lock.json。
• yarn+yarn-lock.json。

根据自身情况选择。
见识有限，欢迎指正，谢谢点赞，完～

前端npmyarnjavascriptnode.js