0 前言
目前项目构建使用npm，或者yarn。通过认识pnpm，看能否使用pnpm代替目前的包管理器，提升项目构建速度。
1 pnpm是什么
pnpm，即performant npm，高性能的npm。相比起目前主流的包管理器，pnpm是速度快、节省磁盘空间的包管理器。
2 性能对比
下面是官网提供的性能对比：
可以看出，与目前主流的包管理器npm、yarn相比，无论有无cache、有无lockfile、有无node_modules，pnpm的安装速度都有明显的优势。
3 节省磁盘空间并提升安装速度
为什么pnpm这么快呢？最主要的原因是，pnpm通过hard link（硬连接）机制，节省磁盘空间并提升安装速度。
hard link（硬链接）:多个文件名指向同一索引节点(Inode)。硬链接的作用 之一是允许一个文件拥有多个有效路径名，这样用户就可以建 立硬链接到重要的文件，以防止“误删”源数据。
当使用 npm 或 Yarn 时，如果你有 100 个项目， 并且所有项目都有一个相同的依赖包，那么， 你在 硬盘上就需要保存 100 份该相同package（依赖包）的副本。
而使用 pnpm，package将被存放在一个统一的位置(如 Mac是 ~/.pnpm-store )。当安装软件包时，其包含的所有文件都会硬链接自此位置，而不会占用额外的硬盘空间。这让你可以在项目之间方便地共享相同版本的package。因此，不会有上面提到的重复安装相同包的问题了。
尝试pnpm install安装依赖，可以看到reused了之前已经安装过的相同的包。
而当安装版本不同的同名软件包时，仅会添加版本之间不同 的文件到存储起中，而不会因为一个文件的修改而保存package的所有文件。
同时该命令提供了一个选项，使用方法为pnpm store prune，它提供了一种用于删除一些不被全局项目所引用到的package的功能。如果需要，开发者可以用这个命令来管理已有的package。
4 node_modules目录的优化
除了节省磁盘空间，pnpm还有另一个重要特点是，建立非扁平的node_modules目录，并在引用依赖的时候通过sybolic link机制找到对应.pnpm目录的地址。为什么需要这样做呢？
4.1 npm@2存在的问题
在npm@2，npm的node_modules目录是非扁平的。比如项目里有一个packagefoo，而foo又有一个packagebar，就会是这个样子：
这样的嵌套安装会有以下的问题：
- package 中经常创建太深的依赖树，这会导致 Windows上的目录路径过?问题。
- 当一个 package 在不同的依赖项中需要时，它会被多次复制粘贴并生成多份文件，导致有大量的依赖的被重复安装。
4.2 npm@3+和yarn存在的问题
于是，在npm@3+ 和 yarn中，通过扁平化处理，解决依赖无法被共用，依赖层级太深的问题，所有的依赖都被平铺在node_modules中的一级目录。如：
但是多个版本的包只有一个(最先安装的一个) 被提升上来，其余版本的包还是会嵌套安装到各自的依赖当中，上面提到的路径过长和重复安装的问题没有彻底解决。
而且，提升依赖包会带来一个新的问题：Phantom dependencies（幽灵依赖），即被提升的包没有在package.json中被依赖， 但是用户却能够引用到这个包。
4.3 pnpm的解决方案
使用pnpm安装依赖，打开node_modules，我们可以看到，node_modules目录是非扁平的（与npm@2一样），同时还多了一个.pnpm的目录。而node_modules下的依赖包都是sybolic link（软链接）
打开.pnpm，可以看到，.pnpm以平铺的形式储存着所有的包。node_modules目录里的package都软链到.pnpm下这样的路径:.pnpm/<organization-name>+<package- name>@<version>/node_modules/<name>。
sybolic link（软链接，也叫符号链接):类似于windows系统中的快捷方式，与硬链接不同，软链接就是一个 普通文件，只是数据块内容有点特殊，文件用户数据块中存放的内容是另一文件的路径名的指 向，通过这个方式可以快速定位到软连接所指向的源文件实体。
这样，pnpm 实现了相同模块不同版本之间隔离和复用。而且，node_modules目录是非扁平的，不存在由于提升带来的幽灵依赖问题。
5 小结
pnpm 通过 hard link 在全局里面搞个 store 目录来存储 node_modules 依赖里面的 hard link 地址。这样节省了磁盘空间，并提升安装速度。
node_modules目录是非扁平的，在引用依赖的时候，则是通过 sybolic link 去找到对应虚拟磁盘目录下(.pnpm 目录)的依赖地址。这样，避免了之前npm和yarn扁平/非扁平安装带来的一系列问题。
6 支持monorepo
原本的项目也是使用了monorepo，不知道pnpm是否支持？答案是肯定的，具体使用方法可以看官网的文档。
看来，可以使用pnpm代替目前的包管理器了！尝试了一下，pnpm install的耗时是原来的npm ci的60%，是一次值得的尝试！
7 参考
- 动机|pnpm
- Benchmarks of JavaScript Package Managers|pnpm
- 都2022年了，pnpm快到碗里来！