【一题】package-lock.json 有何作用，如果没有会出现什么问题

用以锁定版本号，保证开发环境与生产环境的一致性，避免出现不兼容 API 导致生产环境报错

在这个问题之前，需要了解下什么是 semver: 什么是 semver

当我们在 npm i 某个依赖时，默认的版本号是最新版本号 ^1.2.3，以 ^ 开头可最大限度地使用新特性，但是某些库不遵循该依赖可能出现问题

「我们看没有 lock 时，线上环境的风险是如何产生的」

• pkg 1.2.3: 首次在开发环境安装 pkg 库，为此时最新版本 1.2.3，dependencies 依赖中显示 ^1.2.3，实际安装版本为 1.2.3
• pkg 1.19.0: 在生产环境中上线项目，安装 pkg 库，此时最新版本为 1.19.0，满足 dependencies 中依赖 ^1.2.3 范围，实际安装版本为 1.19.0，但此过程中引入了 Breaking Change，导致线上bug，且不可测难以调试

而当有了 lock 文件时，每一个依赖的版本号都被锁死在了 lock 文件，每次依赖安装的版本号都从 lock 文件中进行获取，避免了不可测的依赖风险

「但此时依然有问题: 你使用的第三方库的 lockfile 问题。你自己项目中所有依赖都会被锁死，但并不是依照你第三方依赖的 lockfile 进行锁死，这可能出现潜在的问题。」

「举例说明依赖的依赖的 lockfile 可能存在的问题」

你自己的项目依赖 react，而 object-assign 是 react 的依赖

对于 React 的依赖使用 semver 表示如下

• react@^17.0.2
  • object-assign@^4.1.1

在 React 的第三方库中 lockfile 中的库版本为

• react@17.0.2
  • object-assign@4.1.1

而在业务项目中 lockfile 中的库版本为

• react@17.0.2
  • object-assign@4.10.10: 与 react 的 lockfile 中的依赖不符

此时的 object-assign 作为依赖的依赖有可能会存在问题。

所以此时引出下一个问题: 第三方库需要提交 yarn.lock/packagelock.json 吗

实际上，对于库的开发者而言是需要而且必要的，但需要实时把 depdendencies 保持在较新版本或者较小的版本范围，如使用 ~1.2.3 来 代替 ^1.2.3