package-lock.json 有何作用,如果没有会出现什么问题
共 1119字,需浏览 3分钟
·
2021-09-03 13:12
用以锁定版本号,保证开发环境与生产环境的一致性,避免出现不兼容 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