一般提交依赖锁定文件

与其他地方的covered一样，依赖锁定文件，受许多包管理系统支持（例如： composer和bundler）应该被提交到链终端项目中的代码库 - 这样每个试图运行该项目的人都是通过完全测试的一组依赖。

不清楚是否应始终将锁定文件提交到打算包含在其他项目中的包（需要更宽松的依赖项）。但是，Yarn和NPM（由@Cyrille涵盖）在必要时分别智能地忽略yarn.lock和package-lock.json，从而使得始终提交这些锁定文件变得安全。

因此，您应该始终至少提交yarn.lock或package-lock.json 中的一个，具体取决于您使用的是哪个包管理器。

你应该同时提交yarn.lock和package-lock.json吗？

目前，我们有两个不同的软件包管理系统，它们都从package.json安装相同的依赖项集，但它们生成两个不同的锁文件并从中读取。 NPM 5生成package-lock.json，而Yarn生成yarn.lock。

如果您提交package-lock.json，那么您正在构建支持使用NPM 5安装依赖项的人员。如果您提交yarn.lock，那么您正在构建支持使用Yarn安装依赖项的人员。< / p>

您是选择提交yarn.lock还是package-lock.json还是两者都取决于您项目中开发的项目是仅使用Yarn还是NPM 5或两者。如果您的项目是开源的，那么最适合社区的事情可能是提交两者并进行自动流程以确保yarn.lock和package-lock.json始终保持同步。

更新：纱线现已推出an import command，它将从yarn.lock文件中生成package-lock.json个文件。这对于保持两个文件同步很有用。（谢谢@weakish）

在Yarn项目中详细讨论了这个问题：

两者现已关闭。

答案 1 :(得分：15)

您应该提交1个依赖关系树锁文件，但不应同时提交。这还需要标准化纱线或npm（不是两者）来构建+开发项目。

Here's the yarn article on why yarn.lock should be committed, if you standardize on yarn.

如果同时提交yarn.lock文件和package-lock.json文件，则有两种方法可以使2个文件提供不同的依赖树（即使yarn和npm的树分辨率算法相同），确保它们提供完全相同的答案并非易事。由于它不重要，因此不太可能在两个文件中维护相同的依赖树，并且您不希望使用不同的行为，具体取决于构建是使用yarn还是npm完成。

如果纱线从使用yarn.lock切换到package-lock.json（issue here），那么选择要提交的锁定文件变得容易，我们再也不用担心纱线了npm导致不同的构建。 Based on this blog post，这是我们不应该期待的更改（博客文章还介绍了yarn.lock和package-lock.json之间的差异。

答案 2 :(得分：6)

我在考虑同样的问题。以下是我的想法，希望有所帮助：

npm package-lock.json documentation说明如下：

对于npm修改node_modules树或package.json的任何操作，都会自动生成
package-lock.json。它描述了生成的确切树，以便后续安装能够生成相同的树，无论中间依赖性更新如何。

这很好，因为它可以防止“在我的机器上工作”效果。

如果没有此文件，如果您npm install --save A，则npm会将"A": "^1.2.3"添加到您的package.json。当其他人在您的项目上运行npm install时，1.2.4的版本A可能已被释放。由于它是满足package.json中指定的semver范围的最新可用版本，因此将安装此版本。但是如果在这个版本中引入了新的bug呢？这个人会遇到一个问题，你无法重现，因为你有以前的版本，没有任何错误。

通过修复node_modules目录的状态，package-lock.json文件可以防止出现此问题，因为每个人都会拥有相同版本的每个包。

但是，如果你正在编写和发布npm模块怎么办？文档说明如下：

关于package-lock.json的一个关键细节是它无法发布，如果在toplevel包以外的任何地方找到它，它将被忽略。

因此，即使您提交了它，当用户安装您的模块时，他/她也不会获得package-lock.json文件，而只会获取package.json文件。因此，npm将安装满足所有依赖项的semver范围的最新版本。这意味着您总是希望使用依赖项的这些版本来测试模块，而不是在开始编写模块时安装的模块。所以，在这种情况下，package-lock.json显然毫无用处。更多，这可能很烦人。

答案 3 :(得分：4)

这是我的经验法则：如果您正在处理应用程序，请提交锁定文件。如果要维护库，请将其添加到忽略的列表中。无论哪种方式，您都应该在package.json中使用准确的semver范围。 Yehuda Katz（cached）为何时提交Gemfile.lock（Ruby的锁定文件）以及何时提交时写了一个很好的解释。至少阅读tl; dr部分。

答案 4 :(得分：2)

这些文件由您的工具管理，因此假设使用yarn将有效地更新package-lock.json - 我认为提交两个文件都可以正常工作。

我认为对您的用户来说最重要的是yarn.lock（例如，我不使用纱线）所以要提交。

对于yarn.lock，这取决于您是单独工作还是团队工作。如果是solo，那么我认为没有必要提交它。如果你（计划）在团队中工作，那么你可能应该提交它，至少在纱线supports it

之前

我想纱线团队最终将停止使用package-json.lock并使用{{1}}代替，此时它会变得更简单

答案 5 :(得分：0)

您是对的！允许同时使用npm和yarn会引起问题。看一下this article。

当前，我们计划向在同一存储库中同时使用 yarn和npm的用户添加一些警告。

如果您决定使用yarn，我们强烈建议您删除package-lock.json文件，以避免将来造成混乱和可能的一致性问题。

您可能不希望npm和yarn都作为您的包管理器。

答案 6 :(得分：0)

否，同时使用两个锁定文件通常会导致依赖性树不一致，尤其是在团队协作时。忽略一个或另一个锁是一个简单的解决方案。只要确保您的团队了解并同意此更改即可。