我应该提交 yarn.lock 文件吗？它的用途是什么？

是的，您应该签到，请参阅Migrating from npm

它有什么用？
npm 客户端不确定地将依赖项安装到 node_modules 目录中。这意味着根据安装依赖项的顺序，node_modules 目录的结构可能因人而异。这些差异可能会导致在我的机器上工作 需要很长时间才能找到的错误。

Yarn 通过使用锁定文件和确定性和可靠的安装算法解决了有关版本控制和非确定性的这些问题。这些锁定文件将已安装的依赖项锁定到特定版本，并确保每次安装在所有机器上的 node_modules 中产生完全相同的文件结构。

---

取决于你的项目是什么：

您的项目是应用程序吗？然后：是的，您的项目是图书馆吗？如果是这样：否

可以在 this GitHub issue 中找到对此更详细的描述，其中 Yarn 的创建者之一，例如。说：

package.json 描述了原作者想要的预期版本，而 yarn.lock 描述了给定应用程序的最后一个正确的配置。

只会使用顶级项目的 yarn.lock 文件。因此，除非某个项目将单独使用而不安装到另一个项目中，否则提交任何 yarn.lock-file  是没有用的——相反，它始终取决于 package.json-file 来传达哪些版本的依赖项项目预计然后。

---

我看到这是两个独立的问题。让我两个都回答。

您应该将文件提交到 repo 吗？

是的。如 ckuijjer's answer 中所述，建议在 Migration Guide 中将此文件包含在 repo 中。请继续阅读以了解为什么您需要这样做。

什么是 yarn.lock？

它是一个文件，用于存储项目的确切依赖版本以及每个包的校验和。这是 yarn 为您的依赖项提供一致性的方式。

要了解为什么需要此文件，您首先需要了解原始 NPM 的 package.json 背后的问题是什么。安装包时，NPM 将存储依赖项的允许修订范围，而不是特定修订 (semver)。 NPM 将尝试在指定范围内获取更新依赖最新版本的依赖（即不间断的补丁更新）。这种方法有两个问题。

依赖关系作者可能会发布补丁版本更新，而实际上会引入会影响您的项目的重大更改。两个在不同时间运行 npm install 的开发人员可能会得到不同的依赖集。这可能会导致错误在两个完全相同的环境中无法重现。例如，这可能会导致 CI 服务器的构建稳定性问题。

另一方面，纱线采用最大可预测性的路线。它创建 yarn.lock 文件以保存 exact 依赖项版本。放置该文件后，yarn 将使用存储在 yarn.lock 中的版本，而不是解析来自 package.json 的版本。该策略保证不会发生上述任何问题。

yarn.lock 类似于 npm-shrinkwrap.json，可以通过 npm shrinkwrap 命令创建。检查 this answer 解释这两个文件之间的差异。

---

你应该：

将其添加到存储库并提交它使用 yarn install --frozen-lockfile 而不是 yarn install 作为本地和 CI 构建服务器上的默认值。

（我在 yarn 的问题跟踪器上打开了一张票，以提出使 freeze-lockfile 成为默认行为的案例，请参阅 #4147）。

注意不要在 .yarnrc 文件中设置 frozen-lockfile 标志，因为这会阻止您同步 package.json 和 yarn.lock 文件。请参阅相关的yarn issue on github

yarn install may mutate your yarn.lock unexpectedly，使可重复构建的纱线声明无效。您应该只使用 yarn install 来初始化 yarn.lock 并更新它。

另外，特别是。在较大的团队中，您可能会因为开发人员正在设置他们的本地项目而对纱线锁的更改产生很多噪音。

如需更多信息，请阅读 my answer about npm's package-lock.json，因为这也适用于此处。

最近在 docs for yarn install 中也明确了这一点：

yarn install 在本地 node_modules 文件夹中安装 package.json 中列出的所有依赖项。 yarn.lock 文件的使用如下：如果存在 yarn.lock 并且足以满足 package.json 中列出的所有依赖项，则安装 yarn.lock 中记录的确切版本，并且 yarn.lock 将保持不变。 Yarn 不会检查更新的版本。如果没有 yarn.lock，或者不足以满足 package.json 中列出的所有依赖项（例如，如果您手动将依赖项添加到 package.json），Yarn 会查找满足 package.json 约束的最新可用版本.json。结果写入yarn.lock。如果要确保不更新 yarn.lock，请使用 --frozen-lockfile。

---

根据我的经验，我会说是的，我们应该提交 yarn.lock 文件。它将确保当其他人使用您的项目时，他们将获得与您的项目预期相同的依赖项。

From the Doc

当您运行 yarn 或 yarn add 时，Yarn 将在包的根目录中生成一个 yarn.lock 文件。您无需阅读或理解此文件 - 只需将其签入源代码管理即可。当其他人开始使用 Yarn 而不是 npm 时，yarn.lock 文件将确保他们获得与您完全相同的依赖项。

一种争论可能是，我们可以通过将 ^ 替换为 -- 来实现它。是的，我们可以，但总的来说，我们已经看到大多数 npm 包都带有 ^ 符号，我们必须手动更改符号以确保静态依赖版本。但如果您使用 yarn.lock，它将以编程方式确保您的正确的版本。

也正如 Eric Elliott 所说here

不要 .gitignore yarn.lock。它可以确保确定性的依赖解决方案，以避免“在我的机器上工作”错误。

---

我猜是的，因为 Yarn 版本有自己的 yarn.lock 文件：https://github.com/yarnpkg/yarn

它用于确定性包依赖解析。

---

不要扮演魔鬼的拥护者，但我（多年来）慢慢地意识到你不应该提交锁定文件的想法。

我知道他们所说的每一点文件都说你应该这样做。但这能有什么好处呢？！在我看来，缺点远远大于好处。

基本上，我花了无数个小时来调试最终通过删除锁定文件解决的问题。例如，锁定文件可能包含有关要使用哪个包注册表的信息，并且在不同用户访问不同注册表的企业环境中，这是灾难的根源。

此外，锁定文件确实会弄乱您的依赖关系树。因为 yarn 和 npm 创建了一个复杂的树，并且将不同版本的外部模块保存在不同的位置（例如，在应用程序顶部 node_modules 文件夹中的模块内的 node_modules 文件夹中），如果您频繁更新依赖项，它会造成真正的混乱。再一次，我花了很多时间试图找出一个模块的旧版本仍然在一个依赖项中使用，其中模块版本已经更新，只是发现删除锁定文件和 node_modules 文件夹解决了所有困难- 诊断问题。

现在我什至有 shell 别名，可以在运行 yarn 或 npm 之前删除锁定文件（有时也删除 node_modules 文件夹！）。

我猜只是硬币的另一面，但盲目地遵循这个教条可能会让你付出代价......

---

是的！必须签入 yarn.lock，以便安装依赖项的任何开发人员都能获得完全相同的输出！例如，使用 npm [2016 年 10 月推出]，您可以在本地安装一个 patch 版本（比如 1.2.0），而新开发人员运行新鲜的 install 可能会得到不同的版本 (1.2.1)。

---

是的，你应该提交。有关 yarn.lock 文件的更多信息，请参阅官方文档here

---