何时不使用 package-lock.json

我在 GitHub 上维护着 200 多个仓库，我收到的最常见的 PR 之一就是有人添加了package-lock.json或yarn.lock。这些 PR 未经合并就被关闭了，因为依赖项锁定文件的设计初衷并非供那些本身就是其他软件包依赖项的软件包使用。

出了什么问题？

官方 NPM 文档鼓励将package-lock.json文件提交到源代码版本控制：

强烈建议您将生成的软件包锁提交到源代码管理中：这样，您团队中的其他人、您的部署、您的 CI/持续集成团队以及在您的软件包源码中运行 npm install 的其他人都可以获得与您开发时完全相同的依赖关系树。此外，这些更改的 diff 信息易于阅读，并且会告知您 npm 对 node_modules 所做的任何更改，以便您可以注意到是否有任何传递依赖项被更新、提升等。

–  https://docs.npmjs.com/files/package-locks#using-locked-packages

提交package-lock.json源代码版本控制意味着项目维护人员和 CI 系统将使用特定版本的依赖项，这些依赖项可能与 中定义的版本匹配，也可能不匹配package.json。由于package-lock.json无法添加到 NPM 注册表（设计使然；请参阅NPM shrinkwrap），依赖于使用 的项目的项目package-lock.json本身将用于package.json解析项目的依赖项，即，当项目用作依赖项时，对项目维护人员/ CI 系统有效的方法可能无效。

这种误用的根源在于 NPM 文档。它应该解释，package-lock.json只有当项目不依赖其他项目时才应该提交到源代码版本控制，也就是说，package-lock.json只应该将顶级项目（最终用户使用的程序，而不是其他程序）提交到源代码版本控制。

我已经要求 NPM 更新文档，但它被存档了，没有任何动作。

回应批评

一些评论认为，最大的优点package-lock.json是它允许复制开发环境。

如果某种变体package-lock.json能够以某种方式仅适用于，我会支持它devDependencies。我认为，即使依赖项中存在某个版本损坏，也希望开发环境不会中断，这会带来一些好处（尽管这些好处很小，而且需要权衡）。我个人更希望我的环境能够中断，并意识到我的工具包中某个依赖项需要关注（并根据问题的性质提供帮助、订阅问题或替换依赖项）。毕竟，如果您出于开发目的需要锁定特定版本，您可以轻松修补依赖项树。

然而，目前没有这样的选项，使用锁定文件将会产生本文所述的风险——即您使用的依赖项与用户所依赖的依赖项不匹配。负责任的开发要求您的脚本使用符合语义版本 (semver) 要求的最新版本的依赖项（当然，这包括传递依赖项）。