我们正在为所有确定性 pkg 安装使用 yarn，但不会阻止用户使用 npm - 我猜同时拥有这两个文件会导致问题。应该将一个添加到您的 .gitignore 目录中吗？
一般情况下始终提交依赖锁定文件
正如其他地方所介绍的，依赖关系锁定文件，许多包管理系统都支持这些文件(例如： 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 安装依赖项的人的支持。
您选择提交yarn.lock还是package-lock.json或两者兼而有之，取决于在您的项目上进行开发的人是只使用 Yarn 还是 NPM 5 或两者兼而有之。如果你的项目是开源的，那么对社区最友好的办法可能是同时提交两者，并有一个自动化的流程来确保yarn.lock和package-lock.json始终保持同步。
更新：Yarn 现在引入了一个import命令，该命令将从package-lock.json文件生成yarn.lock文件。这对于保持两个文件同步可能很有用。(谢谢@weakish)
这个问题在 Yarn 项目中进行了详细讨论：
- "想法：从 npm 5 支持包锁.json">
- "竞争锁文件会造成糟糕的用户体验">
两者现已关闭。
您应该提交 1 个依赖树锁定文件，但不应同时提交两个文件。这也需要在纱线或 npm(不是两者)上标准化来构建 + 开发项目。
这是关于为什么应该提交yarn.lock的yarn文章，如果你对纱线进行标准化。
如果您同时提交yarn.lock文件和package-lock.json文件，则 2 个文件可以通过多种方式提供不同的依赖树(即使 yarn 和 npm 的树解析算法相同)，并且确保它们提供完全相同的答案并非易事。由于它不是平凡的，因此不太可能在两个文件中维护相同的依赖树，并且您不希望根据构建是使用 yarn 还是 npm 完成而采取不同的行为。
如果 yarn 从使用yarn.lock切换到package-lock.json(此处存在问题)，那么选择要提交的锁定文件变得容易，我们不再需要担心 yarn 和 npm 导致不同的构建。基于这篇博文，这是我们不应该很快期待的变化(博客文章还描述了yarn.lock和package-lock.json之间的差异。
我在想同样的问题。以下是我的想法，希望对您有所帮助：
npm package-lock.json 文档说：
package-lock.json 是为 npm 修改node_modules树或 package.json 的任何操作自动生成的。它描述了生成的确切树，以便后续安装能够生成相同的树，而不考虑中间依赖项更新。
这很棒，因为它可以防止"在我的机器上工作"效果。
如果没有这个文件，如果你npm install --save A，npm 会"A": "^1.2.3"添加到你的package.json。当其他人在您的项目上运行npm install时，可能已经发布了A的版本1.2.4。由于它是满足package.json中指定的 semver 范围的最新可用版本，它将安装此版本。但是，如果此版本中引入了新错误怎么办？此人会遇到您无法重现的问题，因为您拥有以前的版本，没有任何错误。
通过修复node_modules目录的状态，package-lock.json文件可以防止此问题，因为每个人都将拥有每个软件包的相同版本。
但是，如果您正在编写和发布 npm 模块怎么办？文档说：
关于 package-lock.json 的一个关键细节是它不能发布，如果在顶级包以外的任何地方找到它将被忽略。
因此，即使您提交它，当用户安装您的模块时，他/她也不会获得package-lock.json文件，而只会获得package.json文件。因此，npm 将安装满足所有依赖项的 semver 范围的最新版本。这意味着您始终希望使用依赖项的这些版本来测试模块，而不是在开始编写模块时安装的版本。因此，在这种情况下，package-lock.json显然是无用的。更重要的是，它可能很烦人。
你是对的！ 允许同时使用npm和yarn会导致问题。 看看这篇文章。
目前，我们计划向在同一存储库中同时使用
yarn和npm来安装软件包的用户添加一些警告。如果您决定使用 yarn，我们强烈建议您删除
package-lock.json文件，以避免将来的混淆和可能的一致性问题。
您可能不希望同时使用npm和yarn作为包管理器。
这是我的经验法则：如果您正在处理应用程序，请提交锁定文件。如果要维护库，请将其添加到忽略列表中。无论哪种方式，您都应该在package.json中使用准确的 semver 范围。Yehuda Katz(缓存)写了一个很好的解释，说明何时提交Gemfile.lock(Ruby的锁定文件)以及何时不提交。至少阅读 tl;博士部分。
这些文件由您的工具管理，因此–假设使用 yarn 将有效地更新package-lock.json–我想提交这两个文件都可以正常工作。
我认为对你的用户来说最重要的是package-lock.json(例如，我不使用 yarn)，所以这个必须提交。
对于yarn.lock，这取决于您是单独工作还是团队合作。如果是单独，那么我想没有必要提交它。如果你(计划)在一个团队中工作，那么你可能应该提交它，至少在纱线支持它🙂之前
我想纱线团队最终会停止使用yarn.lock，而是使用package-json.lock，这个时候会变得更简单 😛
不，同时使用这两个锁定文件通常会导致依赖项树中的不一致，尤其是在团队协作时。忽略一个锁或另一个锁是一个简单的解决方案。只要确保您的团队理解并同意此更改即可。