高级前端前端工程化【Q721】npm 第三方库需要提交 lockfile 吗

npm 第三方库需要提交 lockfile 吗

Issue 欢迎在 Gtihub Issue 中回答此问题: Issue 747

Author 回答者: shfshanyue

为何有人说第三方库不需要提交 package-lock.json/yarn.lock?

该观点仅对第三方库的 dependencies 有效

答: 你自己项目中所有依赖都会根据 lockfile 被锁死,但并不会依照你第三方依赖的 lockfile

试举一例:

  1. 项目中依赖 react@^17.0.2
  2. react@17.0.2 依赖 object-assign@^4.1.0

在 React 自身的 yarn.lock 中版本锁定依赖如下:

react@17.0.2
└── object-assign@4.1.0 (PS: 请注意该版本号)

而在个人业务项目中 yarn.lock 中版本锁定依赖如下:

Application
└── react@17.0.2
    └── object-assign@4.99.99 (PS: 请注意该版本号)

此时个人业务项目中 object-assign@4.99.99 与 React 中 object-assign@4.1.0 不符,将有可能出现问题

此时,即使第三方库存在 lockfile,但也有着间接依赖(如此时的 object-assign,是第三方的依赖,个人业务项目中的依赖的依赖)不可控的问题。

第三方库如何解决潜在的间接依赖不可控问题

可参考 next.js 的解决方案。

next.js 源码 点击此处

  1. 将所有依赖中的版本号在 package.json 中锁死。可见 package.json
  2. 将部分依赖直接编译后直接引入,而非通过依赖的方式,如 webpackbabel 等。可见目录 next/compiled

以下是一部分 package.json

{
  "dependencies": {
    "@babel/runtime": "7.15.4",
    "@hapi/accept": "5.0.2",
    "@napi-rs/triples": "1.0.3"
  }
}

除了参考 next.js 直接锁死版本号方式外,还可以仍然按照 ^x.x.x 加勤加维护并时时更新 depencencies

总结

lockfile 对于第三方库仍然必不可少。可见 reactnext.jswebpack 均有 yarn.lock。(PS: 可见 yarn 的受欢迎程度,另外 vue3 采用了 pnpm)

  1. 第三方库的 devDependencies 必须在 lockfile 中锁定,这样 Contributor 可根据 lockfile 很容易将项目跑起来。
  2. 第三方库的 dependencies 虽然有可能存在不可控问题,但是可通过锁死 package.json 依赖或者勤加更新的方式来解决。

Author 回答者: 1gehunzi

对于业务开发者而言第三方库是否锁死自己无法决定吗? 需要库的开发者自觉处理,请问大佬是这样吗

Author 回答者: shfshanyue

@xiyuanyuan 不对,恰好相反。我们是对于间接依赖而言的,在业务方可以锁死,但是库的开发者无法决定他们的依赖在我们业务方的锁死版本号