更好的包管理器——pnpm

此文是对 pnpm的重要贡献者Zoltan Kochan的几篇关于pnpm、monorepo文章的翻译概括，可能存在不准确的部分。

为什么要使用pnpm?

pnpm是一种更高效快捷的包管理器。 Zoltan Kochan认为，yarn只是对npm做了些微改进，提升了速度、增加了一些属性，但并没有改变npm的扁平化依赖结构。而扁平化结构自带以下问题：

1. 模块可以访问自身并不依赖的包；
2. 依赖树的扁平化算法相当复杂；
3. 有一些包不得不拷贝进项目的node_modules目录；

Zoltan Kochan对pnpm的研发投入了更多的时间，pnpm取得了成功，囊括了yarn所有增加的属性：

1. 安全：代码执行前对其进行检查，以确保依赖安装的完整性；
2. 离线模式：pnpm将所有已下载包的压缩文件保存在本地镜像仓库，以实现离线使用，只需要配置--offline参数;
3. 快速：pnpm速度大概是npm和yarn的1/3左右。因为yarn需要拷贝包，而 pnpm只需要把包存在全局仓库，任何需要的地方指向它即可。

比较npm与pnpm的依赖结构

npm@2的node_modules

image.png

• node_modules中的每一个依赖都有其自身的node_modules，所有依赖项都在package.json中指定；
• 如果多个包依赖同一个包a，则a要在不同的包中多次复制；
• 由于依赖关系层层嵌套，树的结构过深会产生长路径。

npm@3的node_modules

为了解决npm@2的问题，npm@3采用扁平化的路径：

image.png

• 就算你只下载一个依赖foo，npm 也会把整个依赖树展平在node_modules根目录下，你可以访问到你没有注册下载的依赖bar@1。如果你的项目使用了bar@1但你没标注在package.json里，一旦foo更新了依赖版本、或者去掉了依赖bar@1，你的项目可能崩溃。

pnpm的node_modules

为了解决npm@2的问题，pnpm把依赖包展平，但是通过软链接把每个包自身的依赖组合在一起。

image.png

• node_modules根节点foo是个软链接。因为node遇到软链接会直接执行其真实路径，所以require('foo') 将会执行路径node_modules/.registry.npmjs.org/foo/1.0.0/node_modules/foo/index.js 的文件 而不是node_modules/foo/index.js;
• 每个包的文件夹下都没有自身的node_modules;
• foo的依赖bar与foo位于文件夹的同一层，两者都属于node_modules；
• foo也可以require('foo')，因为它位于node_modules文件夹下。

pnpm的优势

我的理解：

1. pnpm就是把你项目的所有依赖包都放在了电脑上的一个公共仓库，但是项目里仍然保存着各种包的依赖关系和对应位置，需要哪个就去公共仓库里找。
2. 如果不同项目、同一项目的不同包存在同样的依赖，可以共享同一份依赖。如果需要一个依赖的不同版本，则会单独在公共仓库里下载一下差异文件，从而减少依赖包的总体积，方便快速查找；
3. pnpm需要把所有直接或间接的项目依赖都注册到package.json里，使用pnpm i a的时候不用加--save它也会自动帮你在package.json中注册a。

为什么要把所有代码放到一个仓库？

Zoltan Kochan也曾极力反对monorepo，他认为npm已经拥有为数众多的、颇受欢迎的贡献者，这些人在npm上拥有成百上千个包，每个包都有各自独立的仓库。但是所有人都做的事就是对的吗？不尽然。
实践中，他觉得大多数包都不需要有自己独立的仓库，因为很多情况下一经发布，就不再更新。而且大部分包也无人问津，没那么多人要往你仓库里提代码。而使用同一个仓库，则减少了引用和更新管理的频率，方便迁移。
可以使用pnpm的递归命令来安装所有依赖pnpm recursive install。

参考文献

Why should we use pnpm?
It is OK to keep random things in a single monorepo
pnpm's strictness helps to avoid silly bugs