2017 年，yarn1在 Facebook 工程博客中正式发布。在那时，在首次发布仅 11 个月后，已有超过 175,000 个存储库开始使用yarn作为包管理器。
尽管 Yarn 的成功故事从那时起一直在稳步发展，但该工具也成为许多经典包处理弱点的牺牲品，例如速度缓慢、复杂性增加和数据占用。
Yarn 2 进行了一些根本性的更改，不仅解决了这些问题，还改进了您的整体工作流程。
即插即用支持并不是 Yarn 2 带来的唯一重大变化，Yarn 的维护者在改进上投入了整整一年的时间，
yarn2 采用实际可调试的 CLI 输出，它更加架构化，并且增加的格式和颜色更有利于提高阅读性。
最重要的是，每一行都有自己的错误代码，因此变得更容易调试。
新版本显着减少了文件 I/O 数量，从而在安装过程中节省了一些令人印象深刻的时间。
Yarn 现在在单个pnp.js文件中保存一个映射，它跟踪包引用，并确保节点在运行代码后熟悉正确的位置。
尽管如此，那些下载的软件包需要放在磁盘上的某个位置。这就是新.yarn文件夹的用途。
当 node_modules 最终消失时。
从现在开始，那个位置是你的那些依赖项被缓存的地方，但是——我建议在你自己的项目中测量它——占用的空间要少得多。
虚拟环境 dlx
之前使用运行一个远程的、未安装的包是你必须利用 npm 的东西npx。现在 Yarn 终于发布了自己的命令来做到这一点。
使用 Yarn 2，您可以yarn dlx在临时环境中执行包，而无需先安装它。
补丁协议
在本地修补依赖项现在变得更加容易。您可以使用 Yarn命令 将一个包解压缩到一个临时文件夹中，然后在完成后生成一个包含差异的文件：
yarn patch node-fetch
yarn patch-commit /private/var/patchfolder > mypatch.patch
由于补丁目录从不直接使用，因此几乎没有空间可以搞砸了。您将只参考您的补丁文件：
{
"dependencies": {
"node-fetch": "patch:node-fetch@2.6.1#./mypatch.patch"
}
}
这甚至适用于间接（传递）依赖项，使其成为修补安全问题的重要功能，直到发布正式修复程序！
发布工作流程
如果您在多工作区设置中工作（例如 monorepo），则发布并随后升级树中的所有依赖包可能会成为一项乏味的工作。
理想情况下，您发布了一个新版本的工作区，并且所有依赖项都会使用新版本自动更新。
这正是Version 插件为您所做的。它解锁了新的发布工作流程，消除了必须弄清楚升级什么以及在哪里升级的痛苦。
网友评论