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.3dependencies 依赖中显示 ^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-assignreact 的依赖

对于 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


浏览 55
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报