跳至主要内容

错误代码

信息

您是插件作者,希望声明自己的错误代码,并且这些代码与此处提供的语义不匹配?请放弃一个字符,并使用YNX前缀(例如YNX001)代替YN0

遵守此约定将帮助我们的用户弄清楚哪些错误代码可以在此文档中找到,哪些错误代码应该针对他们使用的插件的单独文档进行检查。

YN0000 - UNNAMED

此代码用于记录常规消息,主要是对齐 Yarn 输出中的所有行。不用担心!

YN0001 - EXCEPTION

程序抛出了异常。

此错误通常永远不会发生(它应该指向此页面上的其他错误消息,以便可以正确记录),因此应将其视为 Yarn 中的错误。随时可以打开一个问题,或者更好的是,提交一个旨在解决此问题的请求。

YN0002 - MISSING_PEER_DEPENDENCY

一个包请求对等依赖项,但依赖项树中它的一个或多个父级未提供它。

请注意,Yarn 在依赖项树的每个级别强制执行对等依赖项。也就是说,如果 ─D> 是依赖项,─P> 是对等依赖项,

# bad
project
├─D> packagePeer
└─D> packageA
└─P> packageB
└─P> packagePeer

# good
project
├─D> packagePeer
└─D> packageA
├─P> packagePeer
└─D> packageB
└─P> packagePeer

根据你的情况,有多种选择

  • packageA 的作者可以通过添加对 packagePeer 的对等依赖项来解决此问题。如果相关,他们可以使用 可选对等依赖项 来实现此目的。

  • packageB 的作者可以通过将 packagePeer 对等依赖项标记为可选来解决此问题 - 但当然仅在对等依赖项实际上是可选的情况下!

  • project 的作者可以通过通过 packageExtensions 配置选项 手动覆盖 packageA 和/或 packageB 定义来解决此问题。

要更多地了解此问题,请查看 此博客文章

YN0003 - CYCLIC_DEPENDENCIES

具有构建脚本的两个包具有循环依赖项。

循环依赖项是一堆麻烦事。当包 A 依赖于包 B,反之亦然时,就会发生这种情况。有时可以通过多个包的链条产生 - 例如当 A 依赖于 B,而 B 依赖于 C,而 C 依赖于 A

虽然循环依赖在一般的 Javascript 案例中可能运行良好(事实上,Yarn 在大多数情况下不会对此发出警告),但一旦涉及构建脚本,它们就会导致问题。事实上,为了构建一个包,我们首先必须确保其自身的依赖项已正确构建。当两个包相互引用时,我们如何做到这一点?由于无法推导出第一个构建的包,因此此类模式会导致每个受影响包的构建脚本被简单地忽略(并发出警告)。

网上已有很好的文档解释如何摆脱循环依赖,最简单的方法是将程序的共享部分提取到一个没有依赖项的第三个包中。因此,我们描述的第一个案例将变成 A 依赖于 CB 依赖于 CC 不依赖于任何内容。

YN0004 - DISABLED_BUILD_SCRIPTS

一个包有构建脚本,但它们已在整个项目中禁用。

可以通过使用 enableScripts 设置在全局范围内禁用构建脚本。发生这种情况时,仍会发出警告,以告知您安装可能不完整。

将警告降级为通知的最安全方法是通过使用 dependenciesMeta[].built 键显式禁用受影响包的构建脚本。

YN0005 - BUILD_DISABLED

一个包有构建脚本,但它们已通过其配置禁用。

可以通过使用 package.json 文件中的 dependenciesMeta 设置在每个项目的基础上禁用构建脚本。发生这种情况时,仍会发出通知,以告知您安装可能不完整。

一个包有构建脚本,但通过软链接链接。

对于 Yarn,当一个包归包管理器所有时,它就是硬链接。在这些情况下,Yarn 通常会将具有构建脚本的包复制到项目本地缓存中,以便具有多个依赖项树的多个项目不使用相同的构建工件。那么所谓的“软链接”有什么问题呢?

当包管理器不拥有包源时,软链接就会出现。一个示例是工作区,或通过 portal: 规范引用的依赖项。在这些情况下,Yarn 无法安全地假定在那里执行构建脚本是预期行为,因为它可能涉及更改你的项目,甚至更糟的是,你的磁盘上可能由多个项目共享的外部位置。由于 Yarn 避免执行任何不安全的操作,因此无法在软链接上运行构建脚本。

有一些解决方法

  • 使用 file: 代替 portal: 将导致使用硬链接而不是软链接。硬币的另一面是包也将被复制到缓存中,这意味着更改包源将要求你运行 YARN_UPDATE_FILE_CACHE=1 yarn install 以便考虑你的更改。

  • 你可以从受影响包的目录中手动运行 yarn run postinstall(或任何命名为你的构建脚本的内容)。这要求你了解它们必须按什么顺序调用,但通常是最安全的选择。

  • 你可以简单地避免在软链接中使用构建脚本。虽然这个建议看起来像是“通过不遇到问题来解决问题”的一个糟糕案例,但请考虑一下,从开发人员体验的角度来看,开发中的构建脚本可能不是最好的效果 - 它们通常意味着你需要在能够看到你的更改之前运行一个脚本,这通常不是你所追求的。

YN0007 - MUST_BUILD

必须构建一个包。

当 Yarn 希望告知您某个软件包需要构建才能完成安装时,将出现此信息消息。这通常只在两种情况下发生:软件包从未构建过,或其之前的构建失败(返回非零退出代码)。

YN0008 - MUST_REBUILD

必须重新构建一个软件包。

当 Yarn 希望告知您某个软件包需要重新构建才能完成安装时,将出现此信息消息。这通常只在一种情况下发生:当软件包的依赖关系树发生更改时。请注意,这也包括其传递依赖项,有时可能会导致意外的重新构建(例如,如果 A 依赖于 B,而 B 依赖于 C@1,并且由于某种原因 Yarn 决定将 C 提升到 C@2,那么 A 将需要重新构建)。

YN0009 - BUILD_FAILED

软件包构建失败。

此问题通常不是由 Yarn 本身引起的,而仅仅意味着描述为具有构建指令的软件包无法成功构建。

要查看实际错误消息,请阅读报告中链接的文件。它将包含失败脚本的完整输出。

YN0010 - RESOLVER_NOT_FOUND

无法为给定软件包找到解析器。

解析器是负责将范围(^1.0.0)转换为引用(1.2.3)的组件。它们各自包含执行此操作的逻辑 - semver 解析器是最著名的解析器,但远非唯一解析器。GitHub 解析器将 GitHub 存储库转换为 tarball URL,Git 解析器对发送到 git 的路径进行规范化,... 每个解析器负责不同的解析策略。缺少解析器意味着缺少其中一种策略。

此错误通常是由 Yarn 插件缺失引起的。

YN0011 - FETCHER_NOT_FOUND

无法为给定软件包找到获取器。

获取器是获取引用并从远程位置获取源代码的组件。semver 获取器可能会从某些注册表中获取软件包,而工作区获取器只会重定向到磁盘上可以找到源的位置。

此错误通常是由 Yarn 插件缺失引起的。

YN0012 - LINKER_NOT_FOUND

找不到给定软件包的链接器。

链接器是从获取器返回的工件中提取源并以目标环境可以理解的方式将它们放在磁盘上的组件。Node 链接器将使用即插即用策略,而 PHP 链接器将使用自动加载策略。

此错误通常是由 Yarn 插件缺失引起的。

YN0013 - FETCH_NOT_CACHED

无法在缓存中找到给定软件包的软件包,将从其远程位置获取。

当从其远程位置下载软件包时,Yarn 会将其存储在一个名为缓存的特定文件夹中。然后,下次下载此软件包时,Yarn 只需检查此目录,并在可用时使用存储的软件包。此消息仅表示无法在此处找到软件包。这不是什么大问题,但你可能应该尽可能限制它 - 例如通过使用零安装

YN0014 - YARN_IMPORT_FAILED

无法从 v1 锁定文件正确导入锁定文件。

v2 版本包含 Yarn 设计方式的重大更改,锁定文件格式就是其中之一。在某些罕见情况下,v1 锁定文件中包含的数据与我们存储在 v2 文件中的数据不兼容。发生这种情况时,Yarn 将发出此警告并再次解析软件包描述符。只有此软件包会受到影响;所有其他软件包将继续按预期导入。

YN0015 - REMOTE_INVALID

远程源返回无效数据。

当解析器和获取器与其通信的远程源返回与我们预期不一致的值(例如因为缺少字段)时,会引发此错误。

YN0016 - REMOTE_NOT_FOUND

远程源返回有效数据,但告诉我们找不到软件包。

当解析器和获取器与其通信的远程源通知它们请求的软件包不存在时,会引发此错误。如果软件包已取消发布,则可能会发生这种情况,并且 Yarn 通常无能为力。

YN0017 - RESOLUTION_PACK

此错误代码目前未使用(它用于打印参与分辨率算法的每个 pass 的包数量,但与它的有用性相比,它被认为过于冗长)。

YN0018 - CACHE_CHECKSUM_MISMATCH

缓存中包的校验和与锁定文件预期的不匹配。

这种情况通常发生在您出于调试目的编辑了缓存中的 zip 存档中的文件之后。使用以下三个命令之一来绕过它

  • YARN_CHECKSUM_BEHAVIOR=reset 将从缓存中删除文件并重新下载它们
  • YARN_CHECKSUM_BEHAVIOR=update 将更新锁定文件以包含新的校验和
  • YARN_CHECKSUM_BEHAVIOR=ignore 将使用现有文件,但不会更新锁定文件

YN0019 - UNUSED_CACHE_ENTRY

在安装依赖项时检测到缓存中的文件未使用。

运行 yarn cache clean 将导致 Yarn 删除 .yarn/cache 中的所有内容。

YN0020 - MISSING_LOCKFILE_ENTRY

在锁定文件中找不到包描述符。

很多命令(例如 yarn run)要求锁定文件处于与当前项目一致的状态才能正常运行。当 Yarn 检测到您的项目引用了锁定文件中未列出的包时,将生成此错误(通常是因为您修改了 dependencies 字段,而没有运行 yarn install,或者因为您添加了一个新的工作区)。运行 yarn install 几乎可以肯定地修复此特定错误。

YN0021 - WORKSPACE_NOT_FOUND

依赖项使用 workspace: 范围,无法解析为现有工作区。

workspace: 协议是 Yarn v2 中出现的新功能,它允许在工作区不存在的情况下,定位当前项目中的特定工作区,而无需冒从其他来源提取数据的风险。此错误明确表示工作区不存在,原因如错误消息中所述。

YN0022 - TOO_MANY_MATCHING_WORKSPACES

此错误应被视为已过时且不存在;如果您遇到此错误,请提出问题。

YN0023 - CONSTRAINTS_MISSING_DEPENDENCY

您的某个工作区应依赖于某个依赖项,但实际上并未依赖。

已生效的 约束 声明指定的工作区必须依赖于指定依赖项的指定范围。由于当前并未依赖,因此 Yarn 在运行 yarn constraints 时会发出此错误。要修复此错误,只需运行 yarn constraints --fix,它将自动修复所有此类错误。

YN0024 - CONSTRAINTS_INCOMPATIBLE_DEPENDENCY

您的某个工作区应依赖于依赖项的特定版本,但实际上并未依赖。

已生效的 约束 声明指定的工作区必须依赖于指定依赖项的指定范围。由于当前并未依赖,因此 Yarn 在运行 yarn constraints 时会发出此错误。要修复此错误,只需运行 yarn constraints --fix,它将自动修复所有此类错误。

YN0025 - CONSTRAINTS_EXTRANEOUS_DEPENDENCY

您的某个工作区不应依赖于其列出的某个依赖项。

已生效的 约束 声明指定的工作区必须依赖于指定依赖项的指定范围。由于当前并未依赖,因此 Yarn 在运行 yarn constraints 时会发出此错误。要修复此错误,只需运行 yarn constraints --fix,它将自动修复所有此类错误。

YN0026 - CONSTRAINTS_INVALID_DEPENDENCY

您的某个工作区列出了无效的依赖项。

已生效一项约束,声明指定的 workspace 在其当前状态下可能不应该依赖于指定的依赖项。由于当前确实如此,Yarn 在运行 yarn constraints 时会发出此错误。修复此错误需要手动干预,因为从 Yarn 的角度来看,修复是模棱两可的。

YN0027 - CANT_SUGGEST_RESOLUTIONS

Yarn 无法为要添加到项目中的包找出合适的范围建议。

在运行 yarn add 而未向要添加的包中添加显式范围时,Yarn 将尝试找到与你的意图匹配的版本。通常这意味着它会优先考虑项目工作区,如果找不到任何工作区,它将尝试查询 npm 注册表以获取已发布版本列表,并使用最高版本。此错误意味着此过程失败,Yarn 无法成功找出应将哪个版本的包添加到你的项目中。

YN0028 - FROZEN_LOCKFILE_EXCEPTION

如果 Yarn 完成安装,你的锁定文件将被修改。

在向 yarn install 传递 --immutable 选项时,Yarn 将确保在此过程中不会修改锁定文件,如果出现这种情况(例如,锁定文件中缺少新添加的包,或者当前 Yarn 版本在能够使用锁定文件之前需要某种迁移),它将引发异常。

此选项通常用于 CI 和生产服务器,修复此错误应只需在本地开发环境中运行 yarn install 并提交包含更新锁定文件的 PR 即可。

YN0029 - CROSS_DRIVE_VIRTUAL_LOCAL

已移除:虚拟机不再使用符号链接实现。

YN0030 - FETCH_FAILED

此错误代码目前未使用;我们理想情况下希望解释为什么获取失败,而不是。

YN0031 - DANGEROUS_NODE_MODULES

Yarn 正在使用 即插即用 安装包,但已找到 node_modules 文件夹。

当检测到您的项目包含似乎实际包含包的 node_modules 文件夹时,会发出此警告。不建议这样做,因为它们可能是您之前使用的任何包管理器的遗留物,并且可能会混淆您的工具并导致您陷入“在我的机器上运行”的情况。

YN0032 - NODE_GYP_INJECTED

在某些情况下,Yarn 可能会检测到包需要 node-gyp,而该包没有明确列出该依赖项。这种行为出于传统原因,不应依赖以下原因

  • 检测是否隐式需要 node-gyp 的主要方法是检查包是否包含 bindings.gyp 文件。但是,执行此检查意味着在 Yarn 解析依赖项树时已知包列表。这需要在解析步骤中获取所有 npm 存档(而不是等到专门的获取步骤),而这一切都只是为了这个有问题的特性。

  • node-gyp 的隐式依赖不会向包管理器提供任何提示,说明哪些版本的 node-gyp 与正在构建的包兼容。Yarn 通过添加对 npm:* 的隐式依赖尽力而为,但它可能是错误的,我们无法知道这一点 - 当使用不兼容的版本编译时,您的安装只会意外崩溃。

通常,省略 node-gyp 的包这样做是为了减少最终依赖关系树中的包数量,因为构建包时不需要(预构建的二进制文件)。虽然这是一个合理的想法,但这样做违背了包管理器规则,我们更愿意通过专门的功能而不是通过此类 hack 来解决此问题。与此同时,我们强烈建议在可能的情况下考虑通过 WebAssembly 预构建本机依赖关系,这样 node-gyp 问题就会完全消失。

YN0046 - AUTOMERGE_FAILED_TO_PARSE

当在 yarn.lock 文件中找到 Git 冲突标记并且无法解析一个或两个候选锁定文件时,会触发此错误。这通常是因为以下两种情况之一

  • 如果你正在使用 Yarn v2 的分支上工作,并且尝试使用 Yarn v1 合并一个分支,则会触发此错误(v1 锁定文件不是 Yaml,这会阻止它们被解析。即使我们能够解析,它们也不包含与 v2 锁定文件相比足够的信息)。

    • 最简单的修复方法是使用 git checkout --theirs yarn.lock,然后再次使用 yarn install(可以随后使用 yarn cache clean 删除不再需要的任何文件)。这将导致重新导入 v1 锁定文件。v2 解析将丢失,但 Yarn 会检测到它并再次解析所有解析。
  • 如果你有多级冲突。Yarn 不支持此类冲突,你必须想办法只保留两级。这通常是通过首先解决两个分支之间的冲突,然后再次在先前步骤和第三个分支的合并结果上解决冲突来完成的。

YN0047 - AUTOMERGE_IMMUTABLE

当在 yarn.lock 文件中找到 Git 冲突标记且 Yarn 在不可变模式下执行时,会触发此错误(yarn install --immutable)。

在此模式下,Yarn 不允许编辑任何文件,甚至不能自动解决冲突。此模式通常用于 CI,以确保在将项目合并到主干之前,项目始终处于正确状态。

为了解决此问题,请尝试在计算机上再次运行 yarn install,但不要使用 --immutable 标志,如果命令成功,则提交更改。

YN0048 - AUTOMERGE_SUCCESS

当在 yarn.lock 文件中找到 Git 冲突标记但 Yarn 自动修复了这些标记时,会发出此信息消息。无需执行其他操作,一切都会开箱即用!

YN0049 - AUTOMERGE_REQUIRED

当在 yarn.lock 文件中找到 Git 冲突标记时,会发出此信息消息。然后,Yarn 将尝试通过遵循其内部启发式方法自动解决冲突。

自动合并逻辑非常简单:它将获取拉取分支的锁文件,通过添加本地分支中的信息对其进行修改,然后再次运行 yarn install 以修复在此过程中可能丢失的任何内容。

YN0050 - DEPRECATED_CLI_SETTINGS

通过其参数(例如 --cache-folder)将选项传递给 CLI 命令时,会触发此错误。

从 v2 开始,不再支持此功能。原因是我们已将所有配置合并到一个可从 yarnrc 文件定义的单一存储中。这可确保所有命令在同一环境中运行(以前的情况并非如此,具体取决于您是否在所有命令或仅在安装中使用 --cache-folder)。CLI 选项现在仅用于控制特定命令的一次性行为(如 --verbose)。

Netlify 用户特别注意: Netlify 目前自动传递 --cache-folder 选项给 Yarn,并且您无法禁用它。出于此原因,当我们检测到 Yarn 在 Netlify 上运行时,我们决定将其设为警告,而不是错误(我们仍然忽略该标志)。我们建议在他们的存储库中对相关问题进行点赞,因为我们很可能会在未来的主要版本中移除此特殊情况。

YN0059 - INVALID_RANGE_PEER_DEPENDENCY

一个软件包请求对等依赖项,但提供的范围不是有效的 semver 范围。无法确保提供的软件包满足对等依赖项请求。必须修复范围才能消除警告。这不会阻止解析,但可能会使系统处于不正确状态。

YN0060 - INCOMPATIBLE_PEER_DEPENDENCY

一个软件包请求对等依赖项,但其在依赖项树中的父级提供的版本不满足对等依赖项的范围。应更改父级以提供有效版本或更新对等依赖项范围。这不会阻止解析,但可能会使系统处于不正确状态。

YN0061 - DEPRECATED_PACKAGE

一个软件包被发布者标记为已弃用。避免使用它,请改用弃用消息中提供的替代方案。

YN0062 - INCOMPATIBLE_OS

已移除: 已被 INCOMPATIBLE_ARCHITECTURE 替换。

YN0063 - INCOMPATIBLE_CPU

已移除: 已被 INCOMPATIBLE_ARCHITECTURE 替换。

YN0068 - UNUSED_PACKAGE_EXTENSION

Yarn 检测到一个 packageExtension 未被使用,这意味着选择器与任何已安装的包都不匹配。

YN0069 - REDUNDANT_PACKAGE_EXTENSION

Yarn 检测到一个 packageExtension 是不需要的,这意味着所选包在有和没有扩展的情况下行为相同。

无法安装外部软链接(门户),因为父包中存在不兼容的依赖项版本。这会阻止 node_modules 安装的门户表示,而无需将文件写入门户的目标目录,出于安全原因,这是禁止的。

解决方法如果门户目标和门户父级之间的冲突依赖项的范围重叠,则解决方法是使用 yarn dedupe foo(其中 foo 是冲突的依赖项名称)将冲突的依赖项升级到最高可用版本,如果 yarn dedupe 在没有参数的情况下使用,则项目中的所有依赖项都将升级到 package.json 中其范围内的最高版本。另一种选择是使用 link: 协议而不是 portal:,并在目标目录中显式安装依赖项。

项目中使用了具有子依赖项的门户依赖项。必须使用 --preserve-symlinks Node 选项才能启动应用程序,以便门户依赖项找到其子依赖项和对等依赖项。

nmMode 已降级为 hardlinks-local,原因是全局缓存和安装文件夹位于不同的设备上。如果您希望 hardlinks-global 生效,请考虑更改 globalFolder 设置,并将全局缓存放置在与您的项目相同的设备上。

YN0075 - PROLOG_INSTANTIATION_ERROR

当 Prolog 谓词使用无效签名调用时,会出现此错误。具体来说,这意味着某些谓词参数未实例化(即没有定义的值),而谓词会期望一些参数。这并不意味着您需要硬编码一个值,而只是意味着在调用谓词之前需要分配一个值。对于大多数 Yarn 谓词的 WorkspaceCwd 参数,这意味着不要调用

workspace_field(WorkspaceCwd, 'name', _).

您还可以使用 workspace/1 谓词让 Prolog 在 workspace_field/3 中使用之前“填充”WorkspaceCwd 参数

workspace(WorkspaceCwd), workspace_field(WorkspaceCwd, 'name', _).

有关在调用错误消息报告的谓词时必须实例化的参数的更多信息,请参阅我们文档中的 专用页面

YN0076 - INCOMPATIBLE_ARCHITECTURE

在清单中(通过 os / cpu / libc 字段)指定了一个软件包与系统架构不兼容。它不会被获取、链接,并且其 postinstall 脚本不会在此系统上运行。

YN0077 - GHOST_ARCHITECTURE

如果某些原生包发出信号表示不支持项目所针对的系统,则可能会从安装中排除这些包。此检测通常基于当前系统参数,但可以使用 supportedArchitectures 配置选项 进行配置。如果此列表中缺少操作系统或 CPU,Yarn 将跳过这些包并发出警告。

请注意,supportedArchitectures 中的所有字段都默认为 current,这是一个根据本地参数而定的动态值。例如,如果你希望支持“我的当前操作系统(无论是什么)和 Linux”,则可以将 supportedArchitectures.os 设置为 ["current", "linux"]

YN0078 - RESOLUTION_MISMATCH

从 Yarn 4 开始,当 Yarn 检测到当前环境是拉取请求时,Yarn 将在 CI 上自动启用 --check-resolutions 标志。在此模式下,Yarn 将检查锁文件解析是否与初始范围一致。例如,给定一个初始依赖项 foo@npm:^1.0.0

  • foo@npm:1.2.0 是一个有效的解析
  • foo@npm:2.0.0 不是一个有效的解析,因为它不匹配预期的语义版本范围
  • bar@npm:1.2.0 也不是一个有效的解析,因为名称不匹配

在正常情况下,此错误永远不会触发,因为 Yarn 应该始终根据依赖项生成令人满意的解析。如果你仍然遇到此错误,则可能是以下两种情况之一

  • Yarn 中存在错误。这种情况可能会发生!仔细检查不匹配之处,如果你有疑问,请在 Discord 上联系我们,我们会告诉你是否需要担心(在这样做之前,请快速查看我们的 存储库问题,以防有人报告了相同行为)。

  • 或者,有人可能在你的锁文件上做奇怪的事情。这可能是一个错误(例如,有人手动修改锁文件进行调试但忘记还原更改),或一个问题(例如,恶意用户试图执行某种 供应链攻击)。

如果用例看起来合法(例如,如果错误来自 Yarn),你可以通过在 yarn install 命令中添加 --no-check-resolutions 标志来绕过对 PR 的检查。但请注意:这是一项安全功能;禁用它可能会产生后果。

YN0080 - NETWORK_DISABLED

enableNetwork 标志设置为 false,防止发出任何请求。

请注意,Yarn 配置允许通过 npmRegistries 逐个注册表设置 enableNetwork

YN0081 - NETWORK_UNSAFE_HTTP

默认情况下,Yarn 将拒绝执行 http(非 https)查询,以保护你免受意外的中间人攻击。

要绕过此保护,请将指定的主机名添加到 unsafeHttpWhitelist

YN0082 - RESOLUTION_FAILED

Yarn 无法找到可以满足所请求范围的软件包版本。这通常发生在针对尚未发布的版本的语义版本范围(例如,当最新版本为 0.9.0 时为 ^1.0.0),但也可能是由其他一些原因引起的

  • 注册表可能未正确设置(因此 Yarn 正在查询公共 npm 注册表,而不是你的内部注册表)

  • 该版本可能已取消发布(尽管这对于公共注册表来说是不可能的)

YN0083 - AUTOMERGE_GIT_ERROR

在自动修复合并冲突时,Yarn 需要知道它必须合并在一起的两个锁文件版本。为此,它将根据情况运行 git rev-parse MERGE_HEAD HEAD 和/或 git rev-parse REBASE_HEAD HEAD。如果这两个命令都失败,则合并无法成功。

如果有人在未解决合并冲突的情况下意外提交了 lockfile,可能会发生这种情况 - 如果发生这种情况,您需要将 lockfile 还原到较早的工作版本并运行 yarn install

YN0085 - UPDATED_RESOLUTION_RECORD

当项目中添加或删除 lockfile 条目时,会打印此消息。

YN0086 - EXPLAIN_PEER_DEPENDENCIES_CTA

对等依赖关系有点复杂,调试它们可能需要大量信息。由于 Yarn 尽力将消息保持在一行中,因此我们提供了一个 yarn explain peer-requirements 命令,该命令比我们在常规安装中显示的内容更详细。

要使用它,只需将原始对等解析错误消息中提供的以 p 为前缀的代码传递给它即可

YN0087 - MIGRATION_SUCCESS

从一个主要版本迁移到下一个主要版本时,一些默认值可能会发生变化。在这种情况下,Yarn 将尝试通过在您的配置设置中固定其值来暂时保留旧的默认值。

要查看此消息出现时应用的确切更改,请检查 .yarnrc.yml 文件的内容以及存储库签出中可能显示为已修改的任何其他文件。

YN0088 - VERSION_NOTICE

在本地机器上,Yarn 会定期检查是否有新版本可用。如果有,将打印一条信息消息一次,然后静默,直到第二天。

如果您不想升级,则不必升级 - 但通常来说,保持 Yarn 为最新版本是个好主意,因为它们往往会带来大量的性能改进、错误修复和新功能。

YN0089 - TIPS_NOTICE

我们的研究表明,即使是我们的高级用户也不总是了解 Yarn 中一些不太明显的功能。为了提高可发现性,在本地计算机上,Yarn 每天都会显示一条关于其包含的一些精华内容的提示。也许其中一条提示可以帮助您在某天改进您的基础设施?

YN0090 - OFFLINE_MODE_ENABLED

启用后,enableOfflineMode 标志会指示 Yarn 忽略远程注册表,并且仅从其内部缓存中提取数据。当在网络受限的环境(例如飞机或火车)中工作时,这是一个便捷的模式。

要退出离线工作模式,请通过运行 yarn config --why 来检查它是如何启用的。如果为 <environment>,请在您的终端中运行 unset YARN_ENABLE_OFFLINE_MODE。否则,从相关的 .yarnrc.yml 文件中移除 enableOfflineMode 标志。