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

Question

执行yarn.lock后，Yarn会创建yarn install个文件。

这应该提交到存储库还是被忽略？它的用途是什么？

Answer 1

是的，您应该将其签入，请参阅Migrating from npm

  

Yarn将在您的包的根目录中生成yarn.lock文件。您无需阅读或理解此文件 - 只需将其检入源代码管理中即可。

Answer 2

取决于您的项目：

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

更详细的描述可以在this GitHub issue中找到，其中一个纱线的创造者，例如。表示：

  

package.json描述了原作者所需的预期版本，而yarn.lock描述了给定应用程序的最后已知良好配置。

仅使用顶级项目的yarn.lock - 文件。因此，除非一个项目将独立使用而不安装到另一个项目中，否则提交任何yarn.lock - 文件都没有用 - 而是始终由package.json - 文件来传达什么版本项目期望的依赖项。

Answer 3

我认为这是两个独立的问题。让我回答两个问题。

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

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

什么是yarn.lock？

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

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

1. 依赖性作者可能会发布修补程序版本更新，而实际上会引入一个会影响项目的重大更改。

2. 在不同时间运行npm install的两个开发人员可能会获得不同的依赖关系集。这可能导致错误在两个完全相同的环境中无法重现。例如，这可能会导致CI服务器的构建稳定性问题。

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

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

Answer 4

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

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

Answer 5

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

From the Doc

  

当您运行纱线或纱线添加时，Yarn将在您的包的根目录中生成yarn.lock文件。您无需阅读或理解此文件 - 只需将其检入源代码管理即可。当其他人开始使用Yarn而不是npm时，yarn.lock文件将确保它们与您拥有完全相同的依赖关系。

有人认为，我们可以通过将^替换为--来实现这一目标。是的，我们可以，但总的来说，我们已经看到大多数npm包带有^符号，我们必须手动更改符号以确保静态依赖版本。但是如果使用{{1}它将以编程方式确保您的版本正确。

同样Eric Elliott说here

  

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

Answer 6

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

Answer 7

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

Answer 8

您应该：

1. 将其添加到存储库并提交
2. 在本地和CI构建服务器上都将yarn install --frozen-lockfile和NOT yarn install用作默认值

---

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

     

安装package.json中列出的所有依赖项   在本地的node_modules文件夹中。

     

yarn.lock文件的使用方式如下：

     

  
• 如果存在yarn.lock并且足以满足所有依赖关系   在package.json中列出，在yarn.lock中记录的确切版本是   安装，yarn.lock将保持不变。纱线不会检查   较新的版本。
  
• 如果不存在yarn.lock或不足以满足   package.json中列出的所有依赖项（例如，如果您   手动将依赖项添加到package.json中），Yarn查找最新的   满足package.json中约束的可用版本。的   结果被写入yarn.lock。
  

     

如果要确保未更新yarn.lock，请使用--frozen-lockfile.

Answer 9

不扮演恶魔的拥护者，但是我（多年来）逐渐意识到您不应该提交锁定文件。

我知道他们所写的每一份文件都说您应该这样做。但是它可能有什么用呢？在我看来，其弊端远大于收益。

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

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

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

我猜只是硬币的另一面，但是盲目地遵循这种教条会使你付出代价……..