什么是纱线--pnp?

我设计并实现了PnP,所以我可以花几个小时谈论它

tl;博士: 我们只写 .pnp.js 和 .pnp 文件夹(位于常规纱线缓存之上)。我们不会将配置存储在其他任何地方。

没有即插即用

当你跑的时候 yarn install (即使没有PnP),也会发生一些事情:

1. 如果你使用 offline mirror 功能,我们从注册表下载tarball并将其存储在脱机镜像文件夹中
2. 无论您是否使用离线镜像,我们都会将下载的所有tarball解包,并将其文件存储在纱线缓存中
3. 然后,我们确定应该将缓存中的哪些文件复制到数据库中的哪个位置 node_modules
4. 我们应用计算出的变化(一系列 rsync 运营(基本上)

即插即用

使用PnP,工作流程如下所示:

1. 没有更改,我们从离线镜像中的注册表下载tarball(如果启用)
2. 没有变化,我们仍然将它们解包到纱线缓存中
3. 我们生成一个 .pnp。js 文件1

就这样。除了 .pnp。js 文件(和缓存,但它以前就在那里)。

¹ 正如你提到的,我们还生成了 .pnp 文件夹( .yarn 截至项目中的第2)条。此文件夹包含两种类型的数据:

• 未连接的包是必须是项目本地的包。通常,这些都是带有postinstall脚本的包(我们不能将它们存储到缓存中,因为生成的工件可能因项目而异)。

• 虚拟包,是为依赖关系树中列出对等依赖关系的每个包创建的符号链接。在不深入细节的情况下,它们是设计的必要组成部分,并且需要 require.resolve 像以前一样工作。 这些文件从第二季开始就不存在了

它是如何工作的?

这个 .pnp。js 文件包含类似于以下内容的信息:

webpack@1.0.0 -> /cache/webpack-1.0.0/
              -> it depends on lodash@1.0.0

lodash@1.0.0  -> /cache/lodash-1.0.0/
              -> no dependencies

通过获得这些信息,解析可以正确地推断出 /cache/webpack-1.0.0 打电话给 lodash ,则必须从中加载所需的文件 /cache/lodash-1.0.0 它在实践中有点复杂(我们为提高性能保留了一个反向映射,我们使用相对路径来确保可移植性等),但总体概念是存在的。

奖励回合:即插即用+拉链加载(纱线2)

奖金: 有了纱线2,我们将进一步改进这个工作流程。这就是它的样子:

1. 我们从注册表下载tarball,然后存储到缓存中(离线镜像和缓存之间不再有区别——它们是相同的)
2. 我们产生同样的结果 .pnp。js 像以前一样归档

就这样!正如您所见,我们不再解包(而是在运行时使用节点加载器从包档案中读取它们)。

这样做有一个非常有趣的特性:如果缓存和 .pnp。js 文件在那里,你不需要运行 纱线安装 为你的申请工作!为了确保你拥有这些文件,你只需要将它们添加到你的存储库中,并像处理其他文件一样对它们进行版本设置。

它非常有用,因为你不需要记住跑步 纱线安装 之后 git rebase , git pull 或 git checkout ,您的CI系统将变得更快、更稳定,因为它们不需要特殊设置——只需克隆您的应用程序,它就会正常工作。

² 在别人提到它之前,在存储库中签入二进制文件是非常困难的 perfectly fine .原因是什么 节点单元 在存储库中签入是一件非常糟糕的事情,因为文本文件的数量呈指数级增长,这给Git带来了巨大的压力——从技术上讲,但从哲学上讲,代码审查是不可能的。

在我描述的例子中,我们没有遇到同样的问题,因为文件的数量受到限制(每个包只有一个文件),并且查看它们非常容易——事实上,更好的是,你可以清楚地看到有多少新的包被PR添加到你的项目中!

它只导入你将要使用的软件包的部分,使软件包膨胀 node_modules 文件夹越来越瘦。

例如,如果你只使用lodash或ramda等相对较大的库中的4-5个函数,那么只使用实际使用的最小值可以节省多少。

我相信它还没有100%完全稳定,但仍然是一个很好的选择,让你保持警惕:)