如果package-lock.json锁定它,那么在package.json中声明的"兼容版本"(^版本)有什么意义呢？

Question

我知道主要优点,package-lock.json我同意这一点.它不仅在最后一次安装中锁定下载的版本,而且还锁定了uri ...在大多数情况下,这是必要的,因为它可以复制最相似的项目.

但有一件事对我来说似乎很奇怪,它package.json具有声明依赖性的功能dependency: ^1.0.0,应该让npm在每个安装中下载该软件包的最新版本和兼容版本.

我正在一个我真正需要的项目.否则,每次我的依赖项发布补丁时,都需要进行新的提交更新,package.json只更改版本,因此我的管道也可以覆盖package-lock.json.

简而言之,似乎在package.json使用某个功能时......会package-lock.json阻止那个功能.

我错过了什么吗？

Answer 1

关键package-lock.json是要准确地表示在某个时间点实际存在的树，以便克隆项目的人获得与您拥有的完全相同的树。

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

更多关于包锁的npmjs.com 页面。

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

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

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

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