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

Question

yarn.lock执行a后,Yarn会创建一个文件yarn install.

这应该提交到存储库还是被忽略？它是为了什么？

Answer 1

是的,您应该检查它,请参阅从npm迁移

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

Answer 2

取决于您的项目是什么:

1. 您的项目是应用程序吗？然后:是的
2. 你的项目是图书馆吗？如果是这样的话:不

在这个GitHub问题中可以找到更详细的描述,其中一个是纱线的创造者,例如.说:

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

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

Answer 3

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

你应该把文件提交到repo吗？

是.正如ckuijjer的回答中所提到的,迁移指南中建议将此文件包含在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命令创建的.检查此答案,解释这两个文件之间的差异.

Answer 4

你应该：

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

（我在 yarn 的问题跟踪器上打开了一张票，以说明冻结锁定文件的默认行为，请参阅#4147）。

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

yarn install可能会意外地改变您的 yarn.lock，使 yarn 声称可重复构建无效。您应该只用于yarn install初始化 yarn.lock 并更新它。

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

有关更多信息，请阅读我对 npm 的 package-lock.json 的回答，因为这也适用于此处。

最近在yarn install的文档中也明确说明了这一点：

yarn install

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

该yarn.lock文件的用途如下：

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

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

Answer 5

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

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

Answer 6

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

从文档

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

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

也正如埃里克·埃利奥特在这里所说的

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

Answer 7

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

Answer 8

不是在鼓吹魔鬼，但我已经慢慢（多年来）意识到你不应该提交锁定文件。

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

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

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

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

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

Answer 9

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