这些文件是由您的工具管理的，所以-假设使用纱线将有效地更新 package-lock.json-我认为提交两个文件都可以很好地工作。

我认为最重要的是你的用户是 package-lock.json(例如，我不使用纱线) ，所以这一个 已经要提交。

对于 yarn.lock，这取决于您是单独工作还是在一个团队中工作。如果是独唱，那么我想就没有必要了。如果你(计划)在一个团队工作，那么你可能应该承诺，至少到纱 支持它

我认为纱线团队最终将停止使用 yarn.lock而改用 package-json.lock，在这个时候它将变得更简单

我的经验法则是: 如果您正在处理应用程序，请提交锁文件。如果要维护库，请将其添加到忽略列表中。无论哪种方式，您都应该在 package.json中使用精确的切分范围。耶胡达 · 卡茨(缓存)对何时提交 Gemfile.lock(Ruby 的锁文件)和何时不提交做了很好的解释。至少读一下 tl; dr 部分。

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

Npm 包-lock. json 文档表示:

包裹锁定。对于 npm 修改 node _ module 树或 package.json 的任何操作，都会自动生成 json。它描述了生成的确切树，这样后续的安装能够生成相同的树，而不管中间的依赖性更新如何。

这是伟大的，因为它防止“在我的机器上工作”的效果。

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

通过修复 node_modules目录的状态，package-lock.json文件防止了这个问题，因为每个包都有相同的版本。

但是，如果您正在编写和发布一个 npm 模块，该怎么办呢:

关于包锁的一个关键细节。Json 是不能发布的，如果在顶级包以外的任何地方找到它，它将被忽略。

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

通常总是提交依赖锁文件

与其他地方的 盖好了一样，依赖锁文件也受到许多包管理系统的支持(例如: 应该提交到链末端项目的代码库中，这样每个试图运行该项目的人都可以使用 没错测试的依赖集来运行该项目。

目前还不清楚是否应该始终将锁文件提交到打算包含在其他项目中的包中(在这些项目中，需要更松散的依赖关系)。然而，纱线和 NPM (由@Cyrille 覆盖)在必要的时候分别智能地忽略 yarn.lock和 package-lock.json，使得始终提交这些锁文件是安全的。

因此，您应该根据所使用的包管理器选择 始终提交至少一个 ABC0或 package-lock.json。

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

目前我们有两个不同的包管理系统，它们都从 package.json安装 相同的依赖关系，但是从两个不同的锁文件生成和读取。NPM 5生成 package-lock.json，而纱线生成 yarn.lock。

如果您提交 package-lock.json，那么您正在构建对使用 NPM5安装您的依赖项的人的支持。如果您提交 yarn.lock，那么您正在构建对使用 Yarn 安装依赖项的人的支持。

您是否选择提交 yarn.lock或 package-lock.json或两者都提交取决于在您的项目上开发的那些仅使用纱线或 NPM5或两者都使用。如果您的项目是开源的，那么最有利于社区的做法可能是同时提交两者并拥有一个自动化过程，以确保 yarn.lock和 package-lock.json始终保持同步。

更新: 纱线现在引入了 import指令，它将从一个 package-lock.json文件生成一个 yarn.lock文件。这对于保持两个文件的同步非常有用。(谢谢@弱者)