npm、yarn与pnpm三种不同包管理器的比较

一、Yarn和npm存在的问题

1.npm

早期npm 的 node_modules 采用了嵌套结构，完全按照目录结构来下载依赖树，容易造成依赖黑洞，最关键的是windows上支持的文件路径最长是 260 多个字符。
npm2.x 目录结构：

node_modules
    ├── moduleA
    │   └── node_modules
    │       └── moduleC
    └── moduleB
        └── node_modules
            └── moduleC
                └── node_modules
                    └── moduleD

从上面的目录结构我们能看到，多层的嵌套结构，以及 moduleC 同时被moduleA、moduleB依赖，所以被重复下载了两次。
npm3.x 中对此问题做了改进 ，对node_modules 采用了扁平化结构。将所有的子依赖都提升到根目录下。也就是 hoist 机制：

npm3.x 目录结构：

node_modules
   ├── moduleA
   ├── moduleB
   └── moduleC
   └── moduleD

这在很大程度上解决了地狱依赖的问题，以及磁盘空间的浪费问题，但同时又带来了新的问题：
①幽灵依赖（Phantom dependencies）：
在package.json中没有声明的依赖包，因为被其他包依赖，被下载并提升到 node_modules 根目录下，导致直接可以在项目中去引用。
②版本依赖的不确定性：
同一份 package.json，下载出来的 node_modules 可能不一致的问题。两个依赖包同时依赖的C包的不同版本，C包只有一个版本会被 hoist，那么到底应该提升哪个版本呢，答案是不确定。

npm 5.x 为此新增了 package-lock.json 文件，用来锁定依赖包的版本号，以及确定不同版本如何 hoist 的问题。这确保了同一份 package.json 下载出来的 node_modules 目录结构一致、但幽灵依赖问题仍然没有得到解决。

2.yarn

①采用扁平化的方式管理 node_modules，并且首次提出了离线缓存下载的概念，下载速度大幅提升。yarn 缓存了每次你下载的模块，所以同样模块同样的版本不会发送第二次下载请求，对于没有缓存的模块， yarn 也可以通过并行的网络请求最大限度利用网络资源。

②yarn 在开始安装一个包之前会先用 checksums 来验证，你不用担心本地的缓存的包被破坏了导致安装失败。

③采用yarn.lock用来确定依赖树之间的结构，确保同一个项目生成同样的 node_modules

④ yarn 跟 npm 一样，都没有解决幽灵依赖（Phantom dependencies）的问题。

Yarn常用命令：

yarn init        	 // 项目初始化,等同于npm的npm init
yarn / $ yarn install      // 安装package.json中的依赖包,等同于npm install
yarn add vue        	// 添加并安装依赖包,等同于npm install vue(现在无需加--save,已经成为默认行为)
yarn global add vue      // 全局安装包
yarn remove vue        // 删除依赖包,等同于npm uninstall vue
yarn upgrade       		 // 升级package.json指定的所有依赖包(在package.json指定的版本范围内)
yarn upgrade --latest     //升级package.json指定的所有依赖包,但忽略package.json指定的版本范围,同时package.json中指定的版本将被重写
yarn outdated        	// 列出包的所有依赖项的版本信息。此信息包括当前安装的版本、基于语义版本所需的版本和最新的可用版本
yarn run        		// 列出包里所有可运行的脚本
yarn run dev       	 // 运行package.json中scripts定义的脚本命令,等同于 npm runx

更改Yarn 的下载源为淘宝镜像：

yarn config list 	// 查看config
yarn config list 	// 查看当前目录相关config
yarn config get registry    // 查看当前下载源,初始为https://registry.yarnpkg.com

yarn config set registry https://registry.npm.taobao.org -g  // 更改为淘宝
yarn config set sass_binary_site http://cdn.npm.taobao.org/dist/node-sass -g  

3.pnpm

pnpm在 2017 年发布，是一个快速的，高效的磁盘空间利用的包管理器。它的出现，解决了 npm、yarn 长期以来存在的性能、安全访问等问题。

pnpm 通过使用硬链接和符号链接到全局磁盘内容可寻址存储来管理 node_modules。当我们运行pnpm install进行node_modules安装的时候，会使用软链接和硬链接的方式来节省磁盘空间，提升安装效率。

相关概念解释：

（1）内容寻址存储（Content Addressable Storage，CAS）

它是一种存储和检索数据的方法。
CAS 基于数据的内容计算出唯一的哈希值，并将其用作数据的索引。因此，相同内容的数据块将始终具有相同的哈希值，可以通过哈希值快速检索数据。

（2）硬链接（hard link）节约磁盘空间

硬链接可以理解为源文件的副本，使得用户可以通过不同的路径引用方式去找到某个文件，他和源文件一样的大小但是事实上却不占任何空间。

（3）符号链接（symbolic link）创建嵌套结构

符号链接也叫软链接，它可以理解为快捷方式，pnpm在引用依赖时通过符号链接去找到对应磁盘目录（.pnpm）下的依赖地址。

通过执行pnpm install，安装的node_modules中文件会被分为两部分：.pnpm目录 & 其他

.pnpm目录：存放了所有实际安装的包
其他文件：package.json中声明的包，但是只是生成一个软链接。实际指向.pnpm中安装的包。

pnpm 使用.pnpm目录以平铺的形式储存着所有的包。该目录通过@来实现相同模块不同版本之间隔离和复用，由于它只会根据项目中的依赖生成，并不存在提升，所以它不会存在幽灵依赖（Phantom dependencies）问题。

最后，不论是硬链接或软链接都不会将原本的源文件复制一份，只会占用非常少量的磁盘空间。而关于硬链接或软链接更详细的介绍，由于篇幅关系，我们将在后面的《从pnpm到软硬链接》文章展开。

（4）全局存储（store）

pnpm config get store-dir：查看 pnpm 的全局存储目录
pnpm config set store-dir ~/.my-pnpm-store：修改 pnpm 的全局存储目录

注：

1.如果未配置 pnpm 的全局存储目录，则 pnpm 会在同一硬盘上自动创建一个存储。

2.项目应该与 store 在同一个磁盘上（这是因为硬链接不能跨磁盘使用，因此每个驱动器可能有多余的包），否则 pnpm 会将依赖包复制到项目中，而不是使用硬链接。（当 PNPM 发现项目和 store 不在同一个磁盘上时，它会自动切换到“local”模式，这意味着依赖包会被复制到项目的node_modules目录中，而不是使用硬链接。这样就避免了跨磁盘的硬链接操作可能导致的问题，确保了项目的正常运行。）

总之，pnpm 通过软、硬链接（hark link、symbolic link） + 全局存储（store）结合的依赖管理方式完全实现了依赖树结构的包管理方式，解决了 npm3 及 yarn 中的幽灵依赖和 npm 分身的问题，提升了依赖包的安装速度，减小了磁盘空间占用。

二、功能比较

以下来自pnpm官网：

功能	pnpm	Yarn	npm
工作空间支持（monorepo）	✔️	✔️	✔️
隔离的 node_modules	✔️ - 默认	✔️	✔️
提升的 node_modules	✔️	✔️	✔️ - 默认
自动安装 peers	✔️	❌	✔️
Plug’n’Play	✔️	✔️ - 默认	❌
零安装	❌	✔️	❌
修补依赖项	✔️	✔️	❌
管理 Node.js 版本	✔️	❌	❌
有锁文件	✔️ -pnpm-lock.yaml	✔️ -yarn.lock	✔️ -package-lock.json
支持覆盖	✔️	✔️ - 通过 resolutions	✔️
内容可寻址存储	✔️	❌	❌
动态包执行	✔️ - 通过 pnpm dlx	✔️ - 通过 yarn dlx	✔️ - 通过 npx
辅助缓存	✔️	❌	❌
列出许可证	✔️ - 通过 pnpm licenses list	✔️ - 通过插件	❌