我应该提交 yarn.lock 和 package-lock.json 文件吗？

一般总是提交依赖锁文件

与其他地方的 covered 一样，许多包管理系统（例如：composer 和 bundler）支持的依赖关系锁定文件应该提交到链末端项目中的代码库 - 以便每个尝试运行该项目是使用 exactly 测试的依赖项集。

是否应该始终将锁定文件提交到旨在包含在其他项目中的包中（需要更松散的依赖关系），这不太清楚。但是，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 现在引入了 an import command，它将从 package-lock.json 文件生成 yarn.lock 文件。这对于保持两个文件同步很有用。 （感谢@weakish）

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

“想法：从 npm 5 支持 package-lock.json”

“相互竞争的锁文件会造成糟糕的用户体验”

两者现在都关闭了。

---

您应该提交 1 个依赖树锁定文件，但不应同时提交。这还需要对 yarn 或 npm（不是两者）进行标准化来构建和开发项目。

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

如果您同时提交 yarn.lock 文件和 package-lock.json 文件，那么这两个文件可以通过多种方式提供不同的依赖树（即使 yarn 和 npm 的树解析算法相同），而且这并非易事确保他们提供完全相同的答案。由于它很重要，因此不太可能在两个文件中维护相同的依赖树，并且您不希望根据构建是使用 yarn 还是 npm 完成不同的行为。

如果当 yarn 从使用 yarn.lock 切换到 package-lock.json (issue here) 时，选择要提交的锁文件变得容易，我们不再需要担心 yarn 和 npm 会导致不同的构建。 Based on this blog post，这是我们不应该很快预料到的变化（博文还描述了 yarn.lock 和 package-lock.json 之间的区别。

---

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

npm package-lock.json documentation 表示以下内容：

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 显然是无用的。更多，这可能很烦人。

---

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

---

你是对的！允许同时使用 npm 和 yarn 会导致问题。看看this article。

目前，我们计划向在同一存储库中同时使用 yarn 和 npm 安装软件包的用户添加一些警告。如果您决定使用 yarn，我们强烈建议您删除 package-lock.json 文件，以避免将来出现混淆和可能的一致性问题。

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

---

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

我认为对您的用户来说最重要的是 package-lock.json（例如，我不使用 yarn），所以这个必须被提交。

对于 yarn.lock，这取决于您是单独工作还是团队合作。如果是单独的，那么我想没有必要提交它。如果你（计划）在一个团队中工作，那么你可能应该提交它，至少在 yarn supports it 之前

我想 yarn 团队最终会停止使用 yarn.lock 并改用 package-json.lock，这时候会变得更简单😛

---

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

---