在执行yarn.lock之后,Yarn将创建一个yarn install文件。

应将其提交到存储库还是忽略?它是做什么用的?

评论

恕我直言,由于缺少“我们应该如何以及何时重新生成yarn.lock文件?”这一问题,该问题(以及以下大多数答案)是不完整的。

您现在知道如何以及何时吗?

@MarkHu在这里找到它:yarnpkg.com/lang/zh-CN/docs/yarn-lock/#toc-managed-by-yarn因此,基本上:您的yarn.lock文件是自动生成的,应完全由Yarn处理。使用Yarn CLI添加/升级​​/删除依赖关系时,它将自动更新yarn.lock文件。

相关:stackoverflow.com/questions/45614973/…

#1 楼

是的,您应该签入它,请参阅从npm迁移
为什么这样做?
npm客户端不确定地将依赖项安装到node_modules目录中。这意味着,根据安装的顺序依赖性,一个人的node_modules目录的结构可能会有所不同。这些差异可能会导致需要很长时间才能找到的我的机器错误的工作。
Yarn通过使用锁定文件和确定性且可靠的安装算法解决了有关版本控制和不确定性的问题。这些锁定文件将已安装的依赖项锁定到特定版本,并确保每次安装都在所有计算机上的node_modules中产生完全相同的文件结构。

评论


好发现。我从他们的文档中发现以下内容,这些内容回答“它是做什么用的?”:“ npm客户端不确定地将依赖项安装到node_modules目录中。这意味着,基于安装的顺序依赖关系,node_modules的结构目录可能因人而异。这些差异可能导致“我的机器上的作品”错误,而这些错误需要很长时间才能找到。”

–rlay3
16-10-12在23:31

续:“ Yarn通过使用锁定文件和确定性和可靠的安装算法解决了版本控制和不确定性方面的这些问题。这些锁定文件将已安装的依赖项锁定到特定版本,并确保每次安装都产生完全相同的文件结构所有计算机上的node_modules。”

–rlay3
16-10-12在23:31

而不是说“未找到锁文件”。它应该只说“ Generate yarn.lock file”。 Duh :)这不是错误,但是前者听起来像是错误。在相反的情况下(后者希望有一个yarn.lock文件,但显然没有),后者将使任何人都感到震惊。

–亚历山大·米尔斯(Alexander Mills)
16-12-3在9:57



我感谢yarn.lock将我们的项目锁定到特定的软件包版本,但是我确实感到遗憾的是使用了“ lock”一词。通常,锁定文件(例如.ldb)是一种将资源一次限制在一个进程中的方法,以防止中间更新导致的损坏。绝对不应将此类锁定文件用于版本控制,这可能是大多数关于yarn.lock的混淆源于此。

– Antony
17年6月27日在12:55

我真的不喜欢“您不需要阅读或理解此文件”这一短语。这是维护项目的重要文件。

–内森·高斯(Nathan Goings)
19年7月10日在19:42

#2 楼

取决于您的项目是什么:


您的项目是应用程序吗?然后:是

您的项目是图书馆吗?如果是这样:否


在GitHub问题中可以找到对此的更详细的描述,其中Yarn的创建者之一。说:


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


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

评论


另一方面,在库项目中拥有锁定文件是否不会影响其各自测试的可重复性?

– E_net4帖子编辑器
16-11-22在19:35



如果我正确阅读了您的描述,则不是“您的项目是图书馆吗?”可以用“如果您愿意”回答。它似乎没有缺点,但是如果您具有复杂的devDependencies并且您希望lib的每个开发人员都具有相同的构建和测试脚本,那么它可能会很有用。对?

– Pipo
16年11月23日在12:10

由于锁文件不会受到您库的任何用户的尊重,因此在开发库时依靠它可能会带来错误的安全感

– VoxPelli
16年11月23日在12:11

Dart与pubspec.yaml和pubspec.lock具有相同的系统,并建议与答案中的相同。请参阅此问题和此文档条目。

–乔纳斯·凯洛(Jonas Kello)
16/12/2在17:25



请在Yarn的官方博客中查看此条目:锁定文件应在所有项目上提交

– E_net4帖子编辑器
16年2月2日在17:45

#3 楼

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

您是否应该将文件提交到repo中?

是的。如ckuijjer的回答中所述,建议在《迁移指南》中将此文件包含在回购中。继续阅读以了解为什么需要这样做。

yarn.lock是什么?

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

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



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

另一方面,纱线采用了最大可预测性的途径。它创建yarn.lock文件来保存确切的依赖版本。将文件放置在适当的位置,yarn将使用存储在yarn.lock中的版本,而不是从package.json中解析版本。此策略保证不会发生上述所有问题。

yarn.lock类似于可以由npm-shrinkwrap.json命令创建的npm shrinkwrap。检查此答案,以解释这两个文件之间的差异。

评论


但是,我看到yarn.lock会不时更新,您知道为什么和何时进行yarn吗?

– Jayarjo
18-10-18在12:20

纱线问题#4379和#4147建议在许多情况下纱线会更新yarn.lock,包括在不更改package.json的情况下运行纱线安装。如为什么在Windows上运行yarn会更改yarn.lock(或通过.yarnrc进行配置)中建议的那样,使用yarn install --frozen-lockfile似乎是最好的选择。

–劳里·哈普夫(Lauri Harpf)
19年5月10日在4:56



如今,npm具有package-lock.json和npm ci。该工作流程类似于yarn的yarn.lock和yarn install --frozen-lockfile。

–k0pernikus
19-09-27在11:20

#4 楼

您应该:


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

(我在yarn的问题跟踪器上打开了一个票证,以使冻结的锁定文件成为默认行为,请参阅#4147。)


请注意不要在frozen-lockfile文件中设置.yarnrc标志因为那样会使您无法同步package.json和yarn.lock文件。请参阅github上的相关纱线问题。yarn install可能会突变您的yarn.lock,从而使可重复构建的纱线声明无效。您只应使用yarn install初始化yarn.lock并进行更新。

此外,尤其是。在较大的团队中,仅由于开发人员正在设置其本地项目,您可能会在纱线锁周围产生很大的噪音。

有关更多信息,请阅读我对npm的卷装锁的回答。 json也适用于此。


最近在纱线安装文档中也对此进行了明确说明:


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中约束的最新可用版本。
结果被写入yarn.lock。

如果要确保yarn.lock没有更新,请使用--frozen-lockfile.


评论


虽然如此,但我唯一能想到的是,必须有人使用--frozen-lockfile,是有人手动更新了package.json而又没有随后运行yarn install和提交更新的情况。因此,CI可能希望使用该标志,但开发人员不应使用该标志,因为它隐藏了问题。

– jkrehm
20-2-3在21:40

@jkrehm取决于隐藏问题的意思。我对纱线安装引入的意外更改yarn.lock文件遇到了更多麻烦,这可能是由于请求请求膨胀,导致不必要的合并冲突,或者是由于破坏了一个库。 (仅因为库使用semvar,并不意味着补丁/次要更新不会破坏您的应用-我去过那里)。我认为更新yarn.lock应该只是一个手动步骤,这就是为什么即使在我的开发机上我也要依靠yarn install --frozen-lockfile(以及npm项目上的npm ci),因为它是可靠且确定的。

–k0pernikus
20年2月4日在9:46

我从未遇到过yarn.lock意外更新的问题(自2016年10月发布以来一直在使用)。一直是用户手动执行某项操作或糟糕的安装后脚本。这就是我比NPM更喜欢Yarn的原因(NPM会随时更新所有内容)。我想我很幸运自己没有遇到那些问题。

– jkrehm
20-2-7在17:37

#5 楼

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

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

#6 楼

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

从Doc



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


有人争辩说,我们可以实现它通过将^替换为--。是的,我们可以,但是总的来说,我们已经看到大多数npm软件包都带有^表示法,并且我们必须手动更改表示法以确保静态依赖版本。但是如果您使用yarn.lock,它将以编程方式确保您的正确版本。 >
就像埃里克·埃利奥特(Eric Elliott)在这里所说的那样


不要.gitignore yarn.lock。它可以确保确定性的依赖关系解析,从而避免“在我的机器上工作”错误。


#7 楼

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

#8 楼

是! yarn.lock必须签入,以便任何安装依赖项的开发人员都能获得完全相同的输出!例如,使用npm [2016年10月可用],您可以在本地安装patch版本(例如1.2.0),而运行全新install的新开发人员可能会使用其他版本(1.2.1)。 >

评论


您提到的npm行为取决于您如何保存依赖项。如果在使用npm时使用--save-exact保存,则可以实现相同的行为。

– AlicanC
16-10-12在18:05

@AlicanC我不这么认为。我相信yarn(通过已提交的锁定文件)将保证软件包的相同版本及其所有依赖关系。这是NPM一直存在的问题,因为依赖项的依赖项可能未固定到特定版本,因此新安装可能会引入其他较低级别的依赖项。 NPM收缩包装本来可以在某种程度上解决此问题,但它总是很棘手,而且经常无法正常工作。

–nextgentech
16-10-12在20:56

@nextgentech如果在这种情况下,我如何确保对依赖关系的依赖关系进行了正确更新。假设我有一个包含一些(比如3个)依赖包的主包。我将注意主程序包中的更改,并在package.json中对其进行更新。但是,如果他们更新了3个子软件包中的任何一个,我将如何获得更改?由于存在锁定文件,这些依赖项将不会更新,对吗?

– Pragatheeswaran
16-10-20在16:05

我还没有完全弄清楚它,但是我相信这是纱线升级命令起作用的地方。此命令将升级所有软件包并重新创建锁定文件。因此,例如,如果您要将应用程序部署到生产环境中并需要安装依赖项,则会基于从存储库中提取的锁定文件来进行安装。除非明确要更改依赖关系信息(从而提交新的锁定文件),否则永远不要运行yarn upgrade。

–nextgentech
16-10-20在19:33



yarn install不能确保版本相同。只有yarn install --frozen-lockfile可以。

–k0pernikus
19-09-27在11:14

#9 楼

不扮演恶魔的拥护者,但多年来(多年来)我逐渐意识到您不应该提交锁定文件。
我知道他们所提供的每一份文件都表明您应该这样做。但是它可能有什么用呢?在我看来,其弊端远大于收益。
基本上,我花了无数小时来调试问题,最终这些问题通过删除锁定文件得以解决。例如,锁定文件可以包含有关使用哪个程序包注册表的信息,并且在企业环境中,不同的用户访问不同的注册表,这是灾难的根源。
此外,锁定文件确实会弄乱您的依赖关系树。因为yarn和npm会创建一棵复杂的树并将不同版本的外部模块放在不同的位置(例如,在应用程序顶部node_modules文件夹中的模块内的node_modules文件夹中),所以如果您频繁更新依赖项,则可能会造成混乱。再次,我花了很多时间试图找出在模块版本已更新的依赖项中仍使用的模块的旧版本,只是发现删除锁定文件和node_modules文件夹解决了所有困难诊断问题。
我现在甚至拥有shell别名,可以在运行yarn或npm之前删除锁定文件(有时甚至删除node_modules文件夹!)。
硬币的另一面,我想,但是盲目地遵循这种教条可能会花费您........