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

纱线在您执行yarn install后创build一个yarn.lock文件。

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

是的，你应该检查它，看到从npm迁移

Yarn将在你的包的根目录下生成一个yarn.lock文件。你不需要阅读或理解这个文件 – 只需将其检查到源代码pipe理。

取决于你的项目是什么：

这个更详细的描述可以在这个GitHub的问题中find，其中Yarn的创造者之一。说：

package.json描述了原始作者所期望的版本，而yarn.lock描述了给定应用程序的最后一个已知好的configuration。

只有顶级项目的yarn.lock文件将被使用。因此，除非项目将被独立使用，而且不会被安装到另一个项目中，否则在提交任何yarn.lock -file时没有用处，而是始终由package.json -file来传达项目的依赖项的版本那么期待。

我看到这是两个单独的问题在一个。让我回答两个问题。

你应该提交文件到回购？

是。正如ckuijjer的回答中所提到的，在“ 迁移指南”中build议将此文件包含到回购中。仔细阅读，了解为什么你需要这样做。

什么是yarn.lock ？

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

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

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

另一方面，纱线走的是最大可预测性的路线。它创buildyarn.lock文件来保存确切的依赖版本。把这个文件放在纱线中将使用存储在yarn.lock的版本，而不是从package.json中parsing版本。这个策略保证没有发生上述问题。

yarn.lock与npm-shrinkwrap.json yarn.lock相似，可以使用npm shrinkwrap命令创build。检查这个答案解释这两个文件之间的差异。

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

它用于确定性包依赖性parsing。

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

从Doc

当您运行纱线或纱线添加时，Yarn将在包装的根目录下生成一个yarn.lock文件。你不需要阅读或理解这个文件 – 只需将其检查到源代码pipe理。当其他人开始使用Yarn而不是npm时，yarn.lock文件将确保它们具有完全相同的依赖关系。

有人认为，我们可以通过用--代替^来实现它。是的，我们可以，但总的来说，我们已经看到大多数npm包都带有^符号，为了确保静态依赖版本，我们必须手动改变符号。但是如果你使用yarn.lock它会以编程方式确保你的版本正确。

正如Eric Elliott 在这里所说的那样

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

是! yarn.lock必须被检入，所以任何安装依赖项的开发者都能得到完全相同的输出！以npm为例，你可以在本地安装patch版本（比如说1.2.0），而运行全新install的新开发者可能会得到不同的版本（1.2.1）。