458

Yarnyarn.lock在您执行yarn install.

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

4

9 回答 9

422

是的，您应该签入，请参阅从 npm 迁移

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

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

于 2016-10-12T07:00:19.530 回答
121

取决于你的项目是什么：

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

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

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

只会使用yarn.lock顶级项目的 -file。因此，除非一个项目将独立使用而不是安装到另一个项目中，否则提交任何yarn.lock-file 都没有用——相反，它总是由package.json-file 来传达项目期望的依赖项版本。

于 2016-10-23T18:01:55.727 回答
80

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

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

是的。正如ckuijjer 的回答中提到的，迁移指南中建议将此文件包含到 repo 中。请继续阅读以了解您为什么需要这样做。

是什么yarn.lock？

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

要了解为什么需要此文件，您首先需要了解原始 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解释这两个文件之间的差异。

于 2016-10-24T01:57:24.130 回答
14

你应该：

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

（我在 yarn 的问题跟踪器上打开了一张票，以提出使 freeze-lockfile 成为默认行为的案例，请参阅#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

在本地 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.

于 2019-09-27T11:12:51.967 回答
13

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

从文档

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

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

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

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

于 2016-12-23T20:45:53.097 回答
11

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

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

于 2016-10-12T03:54:20.320 回答
9

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

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

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

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

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

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

于 2020-09-20T14:58:31.927 回答
7

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

于 2018-01-20T15:11:58.610 回答
5

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

于 2016-10-12T17:22:44.497 回答