如果 package-lock.json 锁定它，那么在 package.json 中声明“兼容版本”（^version）有啥意义？

Posted 2023-03-07

【中文标题】如果 package-lock.json 锁定它，那么在 package.json 中声明“兼容版本”（^version）有啥意义？

【英文标题】：What's the point of having a "compatible version" (^version) declared in package.json if package-lock.json locks it?如果 package-lock.json 锁定它，那么在 package.json 中声明“兼容版本”（^version）有什么意义？

【发布时间】：2019-07-06 06:13:52

【问题描述】：

我知道package-lock.json 的主要优点，我同意这一点。它不仅会锁定上次安装时下载的版本，还会锁定 uri...，这是大多数情况下所必需的，以便尽可能复制最相似的项目。

但我觉得奇怪的一件事是 package.json 具有声明像 dependency: ^1.0.0 这样的依赖项的功能，这应该使 npm 在每次安装时下载该软件包的最新和兼容版本。

我正在从事一个我真正需要它的项目。否则每次我的依赖发布补丁时，都需要重新提交更新package.json，只更改版本，所以我的管道也可以覆盖package-lock.json。

简而言之，似乎package.json 使用了一项功能……package-lock.json 阻止了该功能。

我错过了什么吗？

【问题讨论】：

点击npm install 时，它将安装您锁定的版本。当您点击npm update 时，它将获取最新版本，紧跟 package.json 中定义的边界。 composer 和 yarn 等也是如此，请阅读semantic versioning。通常，无论如何您都不会提交锁定文件。在我们公司，只有当我们使用作者不严格遵守语义版本控制并且在他（/她）代码中放置 API 中断的库时，我们才会提交锁定文件。

@DanFromGermany - 来自npm 团队的指导明确 提交package-lock.json 文件：npm notice created a lockfile as package-lock.json. You should commit this file.More here。当然，这只是他们的指导，任何团队都可以出于自己的原因无视。 :-)

@T.J.Crowder 好的，有道理。理论上，它应该可以在没有问题的情况下工作，只有当作者引入 API 中断时，它才应该是一个问题。但在现实世界中，这有时会导致问题，因此会通知提交锁定文件。

@DanFromGermany - 一个重要的例子实际上是他们修复一个错误。修复 nifty-lib 0.4.0 和 nifty-lib 0.4.1 之间的错误并不少见。如果我们的团队依赖 nifty-lib，而我有 0.4.0，而你有 0.4.1，我看到我们的项目中看起来像一个错误，而实际上它在 nifty-lib 中，但你无法复制它，那可能会导致我们旋转...如果整个团队都使用相同版本的东西，我们会避免该问题，将其追踪到 nifty-lib，npm update，提交更新的锁，然后继续。 :-)

简短的回答是：它使运行npm update 更容易。您是对的：如果您在 package.json 中列出了 someLib: "^1.0.0"，并且锁定文件安装了 someLib: "1.0.0"，您可以 在您的 中将其列为 someLib: "1.0.0" >package.json 文件，运行npm install 时效果相同。但关键是要与人类开发人员沟通该应用程序应使用的版本范围，并使最终用户更容易更新。

【参考方案1】：

package-lock.json 的重点是在某个时间点准确地表示树实际存在，以便克隆项目的人得到完全同一棵树你有。

如果您想将该依赖项升级到更新版本，只需使用npm update，然后提交更新后的package-lock.json。作为获取最新信息的正常过程的一部分，您团队的其他成员将获得该更新。

更多内容请关注npmjs.com page on package locks。

假设你和我在一个团队中，我们的项目使用nifty-lib，package.json 说"nifty-lib": "^0.4.0"，我们不共享package-lock.json。也许我在这个项目上工作的时间比你多几个月，当我安装它时我得到了nifty-lib v0.4.0。但是当你拿起并安装它时，你得到了 v0.4.1（一个错误修复更新，遗憾的是，它引入了一个新错误）。在某些时候，您会注意到我们项目中似乎存在错误，但我无法复制它。我们在原地转了一会儿，试图弄清楚为什么它会发生在你身上而不是我身上。最后，我们意识到这是因为它实际上是他们在 v0.4.1 中引入的nifty-lib 中的一个错误。希望我们能得到 0.4.2 或其他版本（或者如果没有，我们修复错误并进行 PR，同时在整个项目中回滚到 0.4.0）。

如果我们一直在共享 package-lock.json，我们就不会原地踏步想知道为什么问题发生在你身上而不是我身上，因为你会和我拥有相同版本的 nifty-lib。作为我们正常周期的一部分，我们会定期执行npm update，如果在我们的测试中出现新的错误，我们会从提交历史中知道这是因为依赖项中的错误。

现在，“我”和“你”读作“开发”和“生产”。 :-)

这就是为什么package-lock.json 锁定版本，但package.json 让你说“这个或更好”。 package-lock.json 使您的团队在版本上保持统一，但您可以有意地使用 npm update 进行更新，它会显示在提交历史记录中，以便您可以追踪到它的回归。

【讨论】：

谢谢！这似乎很明显，但npm update 正是我所缺少的。现在一切都变得有意义了。 :)

【参考方案2】：

正如我在上面的评论中提到的，简短的回答是它使updateing 您的依赖关系更容易。

但是，我喜欢考虑这两个文件的另一种方式是：package.json 是人类读取的文件，而 package-lock.json 是文件计算机读取。

NPM 是一个包/依赖管理器。因此，在您的 package.json 文件中，您会写出“我的库需要这些库才能正常工作”。作为一个特性，你有一系列的版本，你可以在其中列出一个依赖。当您在特定包上运行 npm update 时，这会有所帮助。它会查看与您的 *package.json** 匹配的最新版本，并更新您的锁定文件。

package-lock.json 锁定文件非常有用，因为它详细描述了您的 node_modules/ 文件夹的外观，因此当其他人安装您的库时可以准确地重新创建它。此外，由于此文件是自动生成的，因此您不必担心维护它。

当然，所有这一切都恰好是 NPM（以及相反地 mostpackagemanagers）处理这个问题的方式。也就是说，我们不能有一个文件来描述运行更新时允许的版本范围和一个详细的锁定文件部分，它固定版本以允许可重新创建的依赖关系树，这没有技术原因。

基本上，这只是一种方便。您有一个文件可以简洁地列出您的项目需要的依赖项。它可读且易于更新。另一个文件 lockfile 是自动生成的，并确保每个 npm install 为您提供与以前完全相同的 node_modules/ 文件夹。