Yarn 2.1 🐱‍🏍 Git 工作区、重点安装、松散模式、实时游乐场……

从一月份以来，你还好吗？从那以后发生了很多事。希望你们无论身在何处，都平安无事。

今天，我们来聊聊 Yarn。就 Yarn 而言，我很高兴地告诉大家，我们的工作进展非常顺利！现在是时候发布下一个次要版本 2.1 了🎉

不过，别被这个小数字蒙蔽了双眼：自上一个版本发布以来，我们已经合并了超过350 个拉取请求！这对于我们的项目来说是一个不可思议的速度，这要归功于我们最喜爱的工具所凝聚的敬业社区🌟

那么 2.1 版本都包含哪些内容呢？真是太多了！我们会介绍主要内容，但更详细的列表可以在我们的代码库中找到。你也应该去看看，里面有很多有趣的小知识！

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

链接器改进

Node 模块链接器

有些人暂时无法迁移到即插即用安装。没关系！我们的一些贡献者并不使用它！Yarnnode_modules也支持安装！感谢Larixer的出色工作，我们很高兴地宣布，即使是大型复杂的仓库也已成功升级到 Yarn 2。我说的大型，是指那些极其庞大的仓库🤓

事实上，我们现在的立场是，Yarn 2 中的 node_modules 链接器比 v1 有了显著的改进。多个代码提升问题已被发现并修复，工作区支持也得到了显著改进。

举个例子，早在 v1 版本中，Babel 就无法使用 Yarn 的默认工作区。我们都希望能够实现这一点，但由于自托管编译器仓库本身的复杂性，这被证明非常具有挑战性。直到现在！Babel 和 Jest 仓库现在都由 Yarn 2 提供支持，坦白说，这是我们所能期待的最好的质量保证。

所以，如果你还在犹豫是否要使用 Plug'n'Play……暂时别用！迁移后就能享受速度、稳定性和用户体验的提升了😃

松散模式

即插即用链接器也得到了改进，引入了松散模式。在松散模式下，如果运行时进行不安全的模块访问，Yarn 只会发出警告，避免抛出硬异常。之所以能做到这一点，是因为我们在安装时生成了原本由 node-modules 链接器生成的提升映射，然后将其用作任何未指定依赖项的后备池。虽然它仍然不安全，但现在您可以快速概览所有潜在问题，而无需立即修复所有问题。

请注意，松散模式默认不启用，因为颇具讽刺意味的是，根据各种因素，它可能会导致比严格模式更冗长的执行。特别是，在try/catch代码块之间包装了可选 require 调用的包将无法阻止警告的发出，从而导致误报。

git:协议的重大改进

工作区克隆

过去几年，大多数项目通常遵循“编辑、提交、推送、发布”的工作流程——前三步在 GitHub 上进行，而第四步则委托给 npm 仓库。当然，从 Git 下载依赖项始终是一个选项，但它并不总是得到应有的重视。尤其是，从 monorepos 克隆特定的包仍然是一个尚未解决的问题。

Yarn 2.1 改变了这种情况。Yarn现在可以从任何 Yarn 项目克隆任何工作区。yarn workspace <name> run build请注意，由于当前 npm 和 pnpm 版本中缺少对应功能，此功能目前仅适用于 Yarn 项目。

尊重构建

瞧，我们（也就是所有软件包管理器的作者们，统称）在过去几年里一直未能解决一个非常重要的误解。它们不可互换。你不能用 X 代替 Y，并期望得到可复现的构建。无论广告宣传如何，每个软件包管理器都有其自身的功能集，期望它们全部同步是徒劳的。当然，我们有时会从其他软件包管理器中实现我们喜欢的功能，但总而言之，每个项目仍然有其自身的特性，其他项目永远无法真正复制。这没关系！

那么，这对于 Git 构建来说意味着什么呢？想象一下，你想使用一个由 pnpm 维护的项目。这很正常。嗯，到目前为止，如果你引用了git:依赖项，Yarn 会克隆它，然后运行yarn install​​，然后yarn pack。一切都很好！但是等等……它运行了吗yarn install？为什么不运行pnpm install？结果发现，没有什么好的理由。正如我所说，包管理器是不可互换的。如果一个项目配置了pnpm-lock.yaml，那么使用 Yarn 安装它是错误的，并且会导致不可预测的构建。显然，这不是一个可接受的行为。

所以我们修复了这个问题！Yarn 现在能够正确检测从 git 依赖项克隆的项目要使用哪些包管理器。如果有yarn.lock，则为 Yarn。如果有pnpm-lock.yaml，则为 pnpm。如果有package-lock.json，则为 npm。

CLI 改进

可读性

输出非常冗长，有时会隐藏重要信息（尤其是在 CI 上，缓存要么一直存在，要么根本不存在）。我们进行了多项改进，以简化输出，使其更易于理解。

• 在终端上，每次只会显示五条获取通知。第六条通知将导致最旧的通知被删除，依此类推。

• 在 CI 上，Yarn 现在将打印一行摘要而不是整个定义（除非另有配置）。

• 新的可选设置preferTruncatedLines将确保信息和警告各占一行，从而使输出保持干净整洁。

• 大多数 CI 系统都会在每个 Yarn 步骤中提供折叠组。我们仍在对此行为进行一些调整，如果您希望讨论此方面更好的集成方案，我们鼓励 CI 维护人员与我们联系。

专注的工作空间

该yarn workspaces focus命令是受 1.x 版同名功能启发而新增的。它允许您仅安装来自特定工作区的依赖项（以及其自身的工作区依赖项），从而显著减少安装大小。结合该--production标志，对于希望将 Monorepos 与 Docker 镜像集成的开发人员来说，它是一个很棒的工具。

顺便说一下，焦点的实现恰好只需要 99 行代码。如果你好奇插件是什么样子的，这是一个很好的例子，值得记住 😉

深度访问yarn config get/set

命令yarn config get/set现在接受深路径（即foo.bar），允许您访问具有不同粒度级别的设置。

此外，现在配置在打印之前总是会被编辑（除非另有要求），从而防止机密意外泄露。

元改进

缓存文件名

我们的缓存文件名过去使用全局缓存键进行版本控制。结果，每次我们不得不修改缓存键（例如，修复 tarball 转换算法中的问题）时，所有文件名都会更改，这会给使用零安装的用户在 Git 历史记录中造成相当大的干扰。

情况已经不再如此，因为我们已将缓存内容索引化。只有存档内容真正发生变化时，每个文件才会发生变化！💫

操场

我们的一位贡献者将 CodeSandbox 和 Yarn 整合到一个令人印象深刻的playground中。通过它，你可以轻松地为遇到的 Bug 构建复现案例，从而减少我们理解和修复 Bug 所需的时间。

文献索引

感谢Algolia的支持，Yarn 网站现已被索引，并可通过状态栏进行搜索。我们希望这能让您快速找到所需的任何信息——无论是身份验证配置、gitignore 示例，还是词典条目。

VSCode Zip 文件系统

我们已在VSCode Marketplace上发布了 Zip FS 扩展。感谢Matt Penrice的贡献，安装扩展后，使用“跳转到定义”功能可以正确地将您引导至正确的文件，并直接从 zip 存档中打开。

请注意，VSCode 有一个内部限制，导致 TypeScript 服务器无法覆盖 zip 压缩包内的文件（例如，您可以从源代码跳转到 zip 文件的定义，但跳转到那里后，TypeScript 不会显示其类型）。请对以下问题点赞以提高该工单的优先级（我们已经提交了 PR，但很遗憾被拒绝了）。

其他改进

演出

• 即插即用运行时已得到进一步优化，在某些情况下可能会产生显著的提升（特别是使用eslint-plugin-import包时的 ESLint）。

• 二进制文件大小也受到了很多关注，2.1 Yarn 二进制文件现在占用 2.35MB，而 2.0 则占用 2.91MB。

 生态系统

• 现在，软件包可以使用清单中的新字段声明其需要解压才能正常运行。这将损害用户体验（您的项目将需要硬安装，这意味着更大的内存占用和更慢的安装速度），因此除非别无选择，否则请不要使用此字段。"preferUnplugged": true

接下来会发生什么？

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

• 添加新dedupe命令来优化依赖树
• 为内置发布工作流程添加变更日志支持
• exports添加对字段的支持
• 添加yarn list＆yarn fund
• 添加遥测支持（RFC）
• 还有更多...！

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

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