我不认为这是一个错误。 我能够重现该问题，但区别在于

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

此更改只是对锁文件的优化，不会更改语义。 我们计划在运行yarn install锁定文件需要更新时添加警告，但如果要确保锁定文件保持相同且准确，则应使用--frozen-lockfile选项。

我必须承认这有点不直观，我们正在努力为此提出一个好的解决方案。 您可以关注或参与有关＃4147的讨论。

如果您同意这不是错误，并且＃4147是继续讨论的好地方，请关闭该问题:)

@BYK感谢您的周到答复。 阅读＃4147后，我对解决此问题持谨慎态度。 我希望在这里进行更多讨论可以有所帮助。

4147似乎完全是关于yarn.lock和package.json不同步的情况-实际上，唯一的优化提到的时间是在此注释中： https : package.json进行任何更改的情况下修改yarn.lock文件。

在我看来，仅当我的依存关系发生某种变化时，才应更改yarn.lock文件。 实际上，到目前为止，我已经告诉开发人员，如果他们看到yarn.lock文件中的更改，那么该运行yarn install 。 在最近的升级中，有几位报告说，他们收到我的更改并运行yarn install ，他们的锁定文件已更改（优化）。 这造成了混乱的局面-他们应该提交更改吗？ 我是否应该以某种方式预先优化锁定文件（甚至可能）？

看起来我可能必须在短期内在所有存储库中将--frozen-lockfile true到.yarnrc -但我不是这种解决方案的忠实拥护者，因为它排除了＃4147，在其中编辑package.json ，然后运行yarn install 。

意图是任何纱线调用都可能会修改yarn.lock吗？

@BYK很抱歉打扰您，因为我知道您很忙-但我希望对此有一个明确的答案。 我用于向团队分发依赖项更改的工作流已分解为：

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

这似乎可以正确更新锁定文件（请参阅＃4476），然后优化锁定文件，以使我的队友无需检查锁定文件的更改。

我的团队使用纱线不正确吗？ 我们是否应该期望锁定文件随每个install命令而改变？

@artlogic恕我直言，应该允许您的队友签入锁文件更改，即使它们只是优化。 我同意这样的观点，即优化锁定文件的yarn install是违反直觉的，但是您团队中的每个开发人员仍然可以放心地这样做。 我不明白您为什么要禁止这样做。

话虽如此，您的工作流程可能会导致意想不到的副作用，因为您几乎放弃了锁定版本。 删除锁文件意味着yarn必须再次解析所有的依赖版本，并且它将尝试获取package.json指出的最新版本，从而导致潜在的破坏，特别是。 如果将来的版本中多个依赖项同时中断。

如果您仍要强制安装不触摸锁文件，则应使用frozen-lockfile标志：

 yarn add {blah}

检入锁文件，然后另一个开发人员将使用：

   yarn install --frozen-lockfile

不要在.yarnrc中将--frozen-lockfile到true ，因为它会阻止您进行更新，请参阅：＃4570

如果要升级依赖项，请运行：

 yarn upgrade

如果只想升级一个依赖项：

  yarn upgrade {blah}

您也可以只安装一个依赖项的特定版本：

  yarn install {blah}@1.5

从长远来看，这允许更多的微调和更少的头痛。

@ k0pernikus-感谢您的详细回复。 首先，对于混淆两个问题，我应该道歉-＃4476正在推动我的某些工作流程。 当然， yarn upgrade似乎已损坏的事实与此问题无关。

至于工作流程，我无法想象我是唯一的团队，其中一个开发人员负责维护/测试新的依赖关系，而其他开发人员则在代码库上工作。 我所遇到的最大问题是，我将安装/测试新的依赖项，告诉所有人运行yarn install ，然后得到4-5个有关是否应提交更改的yarn.lock 。 如果我说“如果锁文件发生更改，请提交”，那似乎就更糟了，因为在那一点上，我可能最终得到看起来像这样的提交锁：

• yarn.lock已更改（dev4）
• yarn.lock已更改（dev3）
• yarn.lock已更改（dev2）
• yarn.lock已更改（dev1）
• 更新的依赖关系（我）

但是，这可能只是yarn的工作方式，因此对于我团队的项目，我们将所有存储库更改为使用冻结的锁文件，以便只有add和upgrade会导致更改锁文件。

另一种情况……对于具有大量贡献者的项目来说，这似乎可能是一个烦人的问题，因为潜在地，每次克隆和安装项目时，锁文件可能都会更改。 我当然不希望在请求请求中进行这些优化。 大多数FOSS项目是否也打算使用纱线过渡到冻结的锁定文件？

@artlogic我们的团队拥有--install.pure-lockfile true项目的.yarnrc正是这种原因。

@jboler-我以前没看过那种设置。 我将不得不看一看，但似乎我建议我们将其添加到.yarnrc以用于我们所有的回购协议以及我拥有的任何FOSS项目的所有回购协议。

如果纱线团队的某人可以确认意图是yarn install可以并且将在每次运行时更改锁定文件（尽管对依赖项没有任何更改），那么我将解决此问题。

@artlogic对不起您的回复。

事实是，可能更改锁定文件的预期是yarn install 。 我知道这并不理想，不过需要更好的沟通。 我真的很想拥有一个更好的默认值，但与此同时，我认为类似@jboler的建议但可能使用--frozen-lockfile会是最好的解决方案，直到我们弄清楚纱线在不同情况下的表现如何，例如人们更喜欢简单地编辑package.json来更新依赖关系的工作流，而不是使用yarn add等。

@BYK我同意@artlogic 。 此行为非常令人困惑：

我所遇到的最大问题是，我将安装/测试新的依赖项，告诉所有人运行yarn install，然后收到4-5个有关是否应提交更改的yarn.lock的问题。

我们的团队由〜50人组成，他们每天都会运行yarn install ：(

@vkrol，您应该能够检入包含--install.frozen-lockfile true或--install.pure-lockfile true的.yarnrc文件，以避免在Yarn更改其行为之前出现问题。 有帮助吗？

@BYK pure-lockfile会帮助我们，但不会帮助frozen-lockfile 。 如果我理解正确，那么启用冻结锁定文件后， yarn install将失败并显示错误。 在我们的情况下，这种行为是绝对不能接受的。

@vkrol我的偏好是frozen-lockfile因为只有当您的锁定文件需要更改并且不一致时，它才会失败。 使用pure-lockfile您可能拥有一个几乎没有用或非常不准确的锁文件，但是您仍然不会失败。 纱线将仅使用其愉快地计算出的内部分辨率。 如果您的所有团队成员都使用完全相同的Yarn版本，那应该没问题。 如果没有，可能很危险。

@BYK也许我不正确理解frozen-lockfile的行为。 当锁文件与package.json内容一致但需要进行一些内部优化时，它是否会失败？

@vkrol ，当可以进一步优化文件时，它应该不会失败，但是它与package.json一致，并且本身也一致。 如果不是，这是一个错误。 甚至还有一个测试： https :

@BYK我不知道。 我将尝试此选项，谢谢！ 我认为这个事实应该记录在某处。

@BYK

当可以进一步优化文件时，它应该不会失败，但是它与package.json一致并且本身也一致。

我发现使用此标志有一些缺点。 如果可以优化yarn.lock，则不会通过“完整性”检查来优化此命令yarn install --frozen-lockfile的重复调用，就像没有此标志一样。 这是一个错误吗？ 我需要创建单独的问题吗？

@BYK感谢您的回复。 对于我团队的项目，我们现在使用frozen-lockfile并且一切正常（相对）。 但是，这个问题对我而言仍然令人担忧。 具体来说，运行yarn install时，yarn对锁定文件进行了不必要的优化。

这是我可以给出的最明显的示例，说明此行为会导致问题：

1. 我使用yarn add [blah]添加一个新的依赖项，并提交更新后的package.json和yarn.lock 。
2. 我的软件包的贡献者拉下更改，并注意到yarn.lock已被更新，因此运行yarn install 。
3. 在某些情况下，这些贡献者在安装后最终会修改yarn.lock 。 在这种情况下，他们应该怎么做？ 这是一场竞赛，看看谁能先提交拉取请求？

要清楚，如果package.json已被修改，则yarn install修改yarn.lock没有问题。 我的问题是package.json未被更改时的优化。 我看到三种可能的解决方案：

1. 指导任何集中管理依赖项的项目将--install.frozen-lockfile true到.yarnrc文件。 这可能是很多项目-我猜想是大多数NPM软件包。
2. 提供一个在添加阶段强制纱线优化锁定文件的开关，例如yarn add --optimize [blah] 。 然后指示软件包维护者始终使用该开关。
3. 禁止在安装阶段优化yarn.lock纱线，除非package.json似乎已更新。

我主张选择方案3，但我也可以看到方案2也是一个合理的选择。

谢谢你的时间！

我有点喜欢yarn install不会更新yarn.lock文件，而是发出警告说“您的yarn.lock文件已过期，请运行yarn blah立即更新。

@BYK为什么〜不〜将纱线优化应用到yarn.lock yarn install yarn.lock yarn install而不是运行add / upgrade的优化上？

编辑：修正错字

@ spencer-brown：根据我所见，它实际上在安装时确实应用了优化-这就是我发现的问题

不应该对yarn.lock进行优化吗？ 无论如何，yarn.lock将会改变。 这是@artlogic最近评论中的

@artlogic oops，错别字:)-我的评论应该说“确实”； 编辑。

我们经常使用composer，而composer install从未接触过锁定文件。

composer update或composer require （相当于yarn add ），才能对锁定文件进行任何更改或优化。

多年来，我们从未担心composer install歧义行为。

我知道yarn扮演的角色略有不同，但是作曲者遇到了手动对composer.json进行更新的问题，并且它与锁定文件不同步。 当前， composer install将完全忽略composer.json文件并发出警告。

我们经常使用composer，而composer install从未接触过锁定文件。

composer update或composer require （相当于yarn add ），才能对锁定文件进行任何更改或优化。

多年来，我们从未担心composer install歧义行为。

我知道yarn扮演的角色略有不同，但是作曲者遇到了手动对composer.json进行更新的问题，并且它与锁定文件不同步。 当前， composer install将完全忽略composer.json文件并发出警告。

嗨，孩子们，锁定文件在以后的安装中永远不会改变。 这只是愚蠢的。 如果您认为优化值得一试，只需创建一个单独的文件即可，而不将其纳入版本控制。

与Bundler的Gemfile.lock一样，yarn.lock的要点是每次运行纱线安装时，您都可以保证在所有环境中都能获得确定的结果。 如果纱线安装更改了锁定文件，您将失去保证。 其他命令（例如添加纱线或更新纱线）显然应更改yarn.lock，但不应安装纱线。 我们的团队遇到了这样的问题：我们在不同的环境中安装了略有不同的软件包版本，这正是我们所不想要的。

我倾向于认为yarn install --pure-lockfile应该是默认值，并且可能会有--fix-my-dev-process-inconsistencies-for-me-magically选项来获取当前行为。

@ryancastle --pure-lockfile不会告诉您更新是针对您的锁文件的。 它只会生成一个。 这仍可能导致意外行为。 如果需要更新， --frozen-lockfile将失败。

我已经在.yarnrc使用--install.frozen-lockfile true进行操作了一段时间，它似乎以一种理智的方式工作。 诀窍是为回购创建初始的yarn.lock ，而该标记无效。 创建完成后，安装程序无法更改yarn.lock ，但更新可以。 一旦开始使用此工作流程，对yarn.lock的意外更改数将降至零。

@artlogic旁注：我以前在.yarnrc中也有frozen-lockfile true ，现在我只在构建服务器上执行它，因为我们遇到了故意更改yarn.lock没有创建package.json同步到yarn.lock ，因为开发人员手动编辑了package.json或使用npm添加了依赖项。

参见： https :

@ k0pernikus的用例是为什么我们没有将--frozen-lockfile作为yarn install的默认值。 老实说，我不知道在不妨碍编辑package.json然后运行yarn install来更新锁文件的人们面前，有什么妥协。 我提出了一个标志或一个新命令，例如yarn sync但是这个想法需要被充实，然后由社区进行判断，然后才能实施。

而且，这将是一个重大变化，因此需要Yarn 2.x :)

标志或新命令，例如yarn sync

对我听起来不错👍。 和yarn install可能会显示一条通知“ package.json和yarn.lock不同步。运行'yarn sync'更新锁文件”

老实说，我不知道在不妨碍编辑package.json然后运行yarn install更新锁文件的人们面前有什么妥协。

我认为在某个时候，需要决定什么是合适的工作流程。 对我而言，启用此功能似乎在鼓励一种反模式。

我提出了一个标志或类似纱线同步的新命令，但是这个想法需要被充实，然后由社区进行判断，然后才能实施。

对我来说，这似乎是一个合理的妥协。 如果您坚持手动编辑package.json ，那么运行命令使事情恢复同步是有意义的。

这是我想看到的：

• yarn install无yarn.lock创建yarn.lock 。
• yarn install与yarn.lock不会修改它。 如果发现yarn.lock和package.json之间存在差异，则会返回错误（如指示的@indeyets ）。
• yarn sync （或者可能是yarn install -s ）返回yarn.lock与package.json同步。

我还有一个潜在的担心， yarn install修改yarn.lock即使package.json不是不同步锁定文件。 您将在上方看到它执行一些“优化”。 至少可以在不作任何更改的情况下禁用此行为吗？

我仍然有一个潜在的担忧，即使package.json与锁文件不同步，yarn安装也会修改yarn.lock。 您将在上方看到它执行一些“优化”。 至少可以在不作任何更改的情况下禁用此行为吗？

同样的想法在这里。 我认为这是此问题仍然存在的特定原因。 由于＃4147中正在讨论“同步”

这就是为什么我首先搜索此问题的原因。

我们将其与＃4147合并吗？

@BYK我认为这里讨论的几乎所有内容都可以与＃4147合并。 就像我之前说过的那样，我认为唯一令我担忧的是即使没有对package.json任何更改， yarn install会对yarn.lock执行的“优化” 。

我的想法是，作为制止纱线2.0的权宜之计，应该禁用这些优化。 我认为这不会是一个重大变化。

我100％同意@artlogic 。

我正在设置CircleCI，并且构建一直失败，并且一直跟踪到yarn.lock的缓存问题。 来自Rails，我希望锁定文件在安装命令中被锁定。

这是在CircleCI上进行缓存检查的建议： https ://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

这永远不会起作用，因为yarn.lock可以更改，而本来不可以。

仅供参考，在macOS 10.13.6下的yarn 1.10.1上，我只是尝试了OP的错误刺激，结果发现yarn.lock并没有改变。 换句话说，当我尝试：

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

因此，当使用纱线1.10.1时， yarn install不会改变yarn.lock ，就像使用纱线1.0.1时的OP一样。 （我认为这是一件好事，就像OP一样。）

@dtgriscom科尔多瓦不再发生问题真是太好了！ 我想知道它是否已完全修复，或者yarn仍可能在安装时尝试优化锁定文件？

很高兴知道，不是吗？ 您注意到该问题是特定于软件包的。 它也可能是特定于版本的，这很有意义。 （我从未听过“我们要更改不应更改的内容”的辩解；除了“我们正在优化”之外……）

我完全同意，默认情况下install操作需要确定性。 更新.lock文件应该要求开发人员执行他知道会在文件中产生更改的操作。 例如，您可以运行类似yarn install --optimize ，以进行小的优化，而不会破坏软件包的当前状态。

仅在文档中添加我必须查看的单独选项，以便我可以确定未经我的许可未锁定文件，这非常令人困惑，尤其是在它们可能导致失败的情况下。 作为一名开发人员，我希望能够控制自己使用的工具，并且我觉得这种行为使我无法控制。

请重新考虑翻转默认行为，以在安装依赖项时不修改锁定文件并仅对其进行操作。 人们真正需要一个带有package.json与锁定文件不同步警告的完整性检查。

我一直在告诉人们，包括对锁定文件进行更改的PR不会合并，因为仅在添加新的或更新的依赖项时才更改锁定文件。 这是安装文档说明的内容：

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 。

文档是否错误，因为上面提到了可以进行的这些优化，还是暂时要考虑的错误？

ps。 它仍然会发生，并且yarn --frozen-lockfile不会失败。

我当前在.yarnrc文件中使用--frozen-lockfile ，在不同机器上运行yarn install时，这可以有效地防止纱线修改yarn.lock文件。 但这也会阻止yarn add blahblah修改我的yarn.lock。 这是正确的行为还是我缺少了什么？ 我已经阅读了整个主题，在我看来， --frozen-lockfile是目前推荐的方法吗？

@konekoya是的，您正确，您当前必须使用

yarn install --frozen-lockfile

并且不能依赖.yarnrc的设置，因为它将阻止您的yarn.lock不断更新。

根据您的.npmrc和.yarnrc您可能可以使用

yarn install --no-default-rc {dependency}

但我不会依靠它（因为一旦在rc文件中进行其他设置，它就会中断。）

请参阅我的评论和相关问题：＃4570，尤其是。 我的结论。

感谢您清除@ k0pernikus。 你让我今天很开心 ：）

@BYK为什么纱线应用优化，以yarn.lock的yarn install ，而不是在add / upgrade正在运行？

我认为@ spencer-brown的评论是“解决”此问题的关键。 我只是为自己进行测试，然后运行yarn upgrade ，然后告诉yarn “已经是最新的”。 因此，我删除了node_modules并运行yarn ，然后生成了“优化的”锁定文件，如果我推送了从yarn upgrade获得的文件，则我项目中的其他开发人员将最终退出该文件。

现在，如果yarn upgrade （和yarn add ）将与yarn install进行相同的优化，那么我们就不会遇到这个问题。 有很多关于不希望破坏任何现有功能的讨论，而且我认为在yarn upgrade和yarn add之后运行优化不会破坏任何东西-只是使其速度变慢了一点。

作为一种解决方法，我正在考虑指示所有开发人员在需要将锁文件推向其他人之前，需要更新锁文件以强制“优化”时删除它们。 或者也许他们可以运行yarn upgrade && yarn prune -也许可以解决问题？

作为一种解决方法，我正在考虑指示所有开发人员在需要将锁文件推向其他人之前，需要更新锁文件以强制“优化”时删除它们。 或者也许他们可以运行yarn upgrade && yarn prune -也许可以解决问题

更新：您无法手动运行修剪，您只会收到以下消息：_“不需要修剪命令。 yarn install将修剪无关的软件包”。_而且由于您无法运行安装，因为_“已经是最新的” _我想我们要删除node_modules，然后运行yarn进行修剪。

对我来说， yarn最大卖点是可预测的，可靠的锁定文件行为。 更改yarn install上的锁定文件使我感到非常焦虑。

对我来说， yarn最大卖点是可预测的，可靠的锁定文件行为。 更改yarn install上的锁定文件使我感到非常焦虑。

锁定文件是作为将要安装的内容的精确规范提供的，因此我们不必担心将要安装的内容。 使用相同的锁定文件，您每次都将获得相同的安装。 但是有时yarn会出于自己的原因而在没有警告的情况下主动更改锁定文件的内容。 是的，您可以说“文件更改不会更改要安装的文件”，但是为什么要采取如此明确的保证并弄混呢？ 为什么让我怀疑是否应该重新提交更改后的锁定文件？ 为什么要ul毁您的主要成名主张？

这真是令人难以置信。 其他人已经很好地说明了这一点。 锁定文件在安装时不应更改。 这会对提交工作流产生负面影响。 我们团队中的每个开发人员都知道在什么情况下可以更改锁文件。 当锁文件更改而不更新依赖项时，这将导致不必要的混乱和额外的检查。 这是刚刚损坏的基本软件包管理器UX。 请解决。

我只是对这种行为感到惊讶，当从Node.js 13迁移到14时，我在执行yarn install时更改了所有yarn.lock文件，我想知道为什么...

我认为适当的行为是如果以任何方式_optimizing_ yarn.lock文件发出警告。