Yarn 2.2 🚅🌟 重复数据删除，更快，更轻......

希望大家度过了一个愉快的夏天！我们一直努力工作，这次更新在各个方面都带来了显著的改进。和往常一样，我们在代码库中保留了详细的列表，现在就让我们来回顾一下其中的亮点吧！

不知道如何升级？很简单：只需yarn set version berry在项目中运行，即可获得最新版本。不想升级？只需还原更改即可！

重复数据删除命令

Yarn 的核心价值之一是可预测性。我们希望您确信您的项目不会突然发生意外变化。lockfile 在其中发挥了重要作用，确保您在安装过程中（现在或将来）始终获得相同的依赖项。

为了解释 dedupe 命令是什么，我首先需要稍微解释一下 lockfile 的格式。在 Yarn 中，我们有描述符（包名和范围的组合），并将它们与引用（版本）关联起来。lockfile 本质上存储了哪个引用链接到了特定的范围。

那么，当你添加新的范围时会发生什么？例如，如果你lodash@^4.0.0的锁文件中已经有 ，解析为4.0.0，然后突然添加lodash@^4.1.0？由于这个新范围与旧范围不兼容，Yarn 需要自行解析它——假设是4.1.0。现在到了有趣的部分——还记得我说过 Yarn 会尽量保持可预测性，因此除非收到命令，否则会避免更新 吗？在这种情况下，这意味着lodash@^4.0.0不会被更新为4.1.0，即使它们兼容。相反，它将继续使用之前使用的其他任何内容，这意味着你的树中最终会同时包含4.0.0和4.1.0。

从功能上来说，这没什么问题，因为两个版本号都会使用与其宣传兼容的版本。然而，实际上，这可能会导致你的锁文件随着时间的推移而无谓地增长，因为它会引用多个软件包副本，尽管如果锁文件允许进行更大范围的更改，它们本来是兼容的。

新的yarn dedupe命令就是我们针对这个问题的解决方案。默认情况下，它会应用一个解析过程，遍历每个范围，并使用锁文件中现有的最高兼容版本。这有以下几个优点：

• 它不需要网络，所以速度非常快
• 最终，大多数重复项将被删除
• 这是可以预见的：最高版本获胜

当然，如果您有不兼容的范围（例如^1和^2），它们将不会被一起进行重复数据删除，因为这会导致无效的树。在这种情况下，您必须修复依赖关系以删除对旧范围的引用。

最后，如果您希望在 CI 上进行此类检查，-c,--check则如果可以进行优化，该选项将导致重复数据删除算法报告错误。

演出

更好的性能带来更好的用户体验，而 Yarn 的核心在于良好的用户体验。为此，我们在 2.2 版本中进行了多项改进，以提升实际项目的性能。例如，Gatsby 在冷缓存上的运行时间从 92 秒缩短至 83 秒，在热缓存上的运行时间从 17 秒缩短至 13 秒。

我们认为，在没有实际数据支持和公开追踪性能下降的情况下，不应该仅仅炫耀性能提升，因此我们与Datadog的合作伙伴一起搭建了一个实时仪表盘，用于展示我们针对大多数常用包管理器进行的每日基准测试结果。我们对结果非常满意！

请注意，Yarn 目前在冷缓存安装方面比同类产品略胜一筹，因为我们需要将注册表存档转换为 zip 格式，这更适合我们的使用情况。随着注册表在这方面的改进，我们预计冷缓存的性能将大幅提升 🚅

尺寸

由于我们建议将 Yarn 二进制文件签入到您的代码库中，因此我们最好注意文件的大小。我们的团队在这方面做了各种改进，Yarn 2.2 现在正好是 1.8MB。举个例子：

• Yarn Classic 大约 5MB
• pnpm 为 35MB
• npm 为 61MB

嗯，1.8MB 不错，不是吗？🙂

遥测

v2 版本中一个有趣的变化是，我们将启用基本的选择退出遥测功能。完整详情请见此处，但主要目的是希望这能让我们花更多时间开发 Yarn 本身，并更好地了解它在整个社区中的使用情况，从而帮助我们做出权衡。

遥测有效载荷可以轻松选择退出，我们致力于尽可能少地发送信息。一旦数据开始流动，我们计划构建公共仪表板（类似于我们的基准），以帮助每个人更好地了解项目。

其他作品

较小的改进

这只是一个非常简短的列表，如往常一样，请查看我们的官方变更日志以获取完整列表，但 2.2 还附带：

• Shell 脚本语言现在支持更多语法（shell 组{ echo foo; echo bar } > bar、基本算术$(($RANDOM + 10))）

• 该--immutable标志现在接受一个immutablePatterns设置，您可以使用该设置来定义在安装过程中不允许更改的其他路径 - 有助于防止更改.pnp.js或其他工件

• 通过协议引用的包file:现在将在再次运行时更新yarn add（它们仍然存储在缓存中 -portal:如果您想要类似符号链接的行为，则最好这样做）。

• 新的publishConfig.executableFiles字段允许您定义包中应标记为可执行文件的路径。默认情况下，由于 Windows 无法表示可执行文件标志，因此只有bin字段中引用的文件才会被标记为可执行文件，但有时您可能需要其他文件。

• 在各种情况下，错误消息都已得到澄清，例如在 Webpack 的浏览器上下文中访问内置 Node 时、在yarn add未知包上运行时，或者在父目录中存在残留的 package.json 时。

网站

网站进行了多项改进。特别是：

• 迁移指南现在提供一步一步的部分，可以帮助您进行迁移，而无需事先阅读整个文档。

• 搜索引擎现在涵盖清单和yarnrc页面，从而更容易找到有关特定字段的信息。

“包管理器管理器”

我们正在与 Node TSC讨论将 Yarn 在某种程度上与 Node 捆绑在一起（目前的计划是发布一个 shim，以便在首次调用 Yarn 时透明地安装）。完整提案可在以下仓库中找到：arcanis/pmm。我们强烈建议您试用一下，并告诉我们您的想法！

通常，此类变更会得到广泛支持，因此如果您使用 Yarn（或 pnpm），请随时关注讨论并在相关时做出贡献。如果您不使用其中任何一个，请记住其他人也会使用，仅仅因为您无法从中直接受益就拒绝该提案，这可能不符合一个包容性社区的理念。

接下来会发生什么？

从现在开始，我们将尝试更定期地发布次要版本，每月只发布一个次要版本（最终在 2021 年 1 月发布 Yarn 3 之前）。我们为下一个版本构思了一些主题（快来帮忙吧！我们有很多Good First Issues！）：

• 全新yarn info
• 新的变更日志生成功能
• 现场的 PnP 支持exports以及一般的 ESM
• 还有更多...！

当然，这只是我脑海中的想法，所以我们的目标可能会在接下来的几周内发生变化，这取决于我们自己的优先事项——当然也取决于你是否帮助我们😛

我们正在着手探索的一个长期课题是为非
JavaScript 语言（例如 C++、Python、Rust、PHP 等）提供包支持。我们已经有一些想法（我们有一个生成 CMake 文件的实验分支，还有一位贡献者正在使用 Python），我们将在接下来的几个月里持续评估实现这一目标所需的工作。如果您熟悉这些生态系统中的任何一个，并且有兴趣帮助 Yarn 成为通用的包管理器，请在Discord上联系我们！

在此之前，请注意安全，戴上口罩，下个月见😉