浅谈前端包管理工具以及区别

前言

作为一名前端工程师，基本每天都会跟 xxx install 打交道，包管理器已经是前端生态中必不可少的工具。本文主要是介绍了npm、yarn和pnmp这三种常见的包管理器。如果文中有错误欢迎指正交流~

npm

npm 是 JavaScript 运行时环境 Node.js 的默认包管理器。在我们安装 Node.js 时，npm 也是默认安装的。它于 2009 年作为开源项目被创建，并且在 2010 年发布。 2020 年 npm 正式被 Github 收购。

npm v3 之前的嵌套式结构

npm v3 之前采用的是嵌套的node_modules 结构，项目中的直接依赖会平铺在node_modules下，而子依赖项则平铺在直接依赖的node_modules下。举个例子：

node_modules
├── A@1.0.0
│   └── node_modules
│       └── B@1.0.0
└── C@1.0.0
    └── node_modules
        └── B@2.0.0

项目依赖了 A 和 C，而 A 和 C 依赖了不同版本的B@1.0和 B@2.0，则会分别在 A 和 C 下面都安装不同版本的 B，这样看起来很正常，但如果项目中新增一个依赖 D，而 D 也依赖B@1.0，则会生成下面的嵌套结构：

node_modules
├── A@1.0.0
│   └── node_modules
│       └── B@1.0.0
├── C@1.0.0
│   └── node_modules
│       └── B@2.0.0
└── D@1.0.0
    └── node_modules
        └── B@1.0.0

我们可以看到同版本的 B 被安装了两次。那这种设计在真实的开发场景下，依赖增多，冗余的包也会越来越多，node_modules 最终会堪比黑洞，很快就会把磁盘占满。而且依赖嵌套的深度也会十分可怕，这个就是依赖地狱。

npm v3 之后的扁平化结构

为了优化依赖地狱这一问题，npm v3 将子依赖进行"提升"，采用扁平化的 node_modules 结构，子依赖会尽量平铺安装在主依赖项所在的目录中。

node_modules
├── A@1.0.0
├── B@1.0.0
└── C@1.0.0
    └── node_modules
        └── B@2.0.0

可以看到 A 的子依赖B@1.0不再嵌套到 A 的下级了，而是与 A 同一层级。而 C 的依赖项因为版本原因依然还是嵌套在 C 的 node_modules 下。这样不会造成大量包的重复安装，依赖层级也不会太深，解决了依赖地狱的问题，但是也形成了新的问题。

幽灵依赖

幽灵依赖是指在package.json中未被定义的依赖，但是在项目中依然可以被正确的引用到。比方说一个项目只安装的 A 和 C，A 依赖B@1.0，C 依赖B@2.0，那么它的package.json如下：

{
  "dependencies": {
    "A": "^1.0.0",
    "C": "^1.0.0"
  }
}

安装后的 node_modules 如下：

node_modules
├── A@1.0.0
├── B@1.0.0
└── C@1.0.0
    └── node_modules
        └── B@2.0.0

由于 A 依赖的 B 在安装时被提升到了和 A 同样的层级，所以在项目中引用 B 还是能正常工作的。幽灵依赖是由依赖的声明丢失造成的，如果某天某个版本的 A 依赖不再依赖 B 或者 B 的版本发生了变化，那么就会造成依赖缺失或兼容性问题。

不确定性

不确定性是指同样的package.json文件，install 依赖后可能不会得到同样的 node_modules 目录结构。还是之前的例子，A 依赖B@1.0，C 依赖B@2.0，依赖安装后究竟应该提升 B 的 1.0 还是 2.0。

node_modules
├── A@1.0.0
├── B@1.0.0
└── C@1.0.0
    └── node_modules
        └── B@2.0.0

node_modules
├── A@1.0.0
│   └── node_modules
│       └── B@1.0.0
├── B@2.0.0
└── C@1.0.0

这其实取决于用户的安装顺序。如果有package.json变更，本地需要删除 node_modules 重新 install，否则可能会导致生产环境与开发环境 node_modules 结构不同，代码无法正常运行。

依赖分身

假设继续再安装依赖 B@1.0 的 D 模块和依赖@B2.0 的 E 模块，此时：

A 和 D 依赖B@1.0
C 和 E 依赖B@2.0

以下是提升 B@1.0 的 node_modules 结构：

node_modules
├── A@1.0.0
├── B@1.0.0
├── D@1.0.0
├── C@1.0.0
│   └── node_modules
│       └── B@2.0.0
└── E@1.0.0
    └── node_modules
        └── B@2.0.0

可以看到B@2.0会被安装两次，实际上无论提升B@1.0还是B@2.0，都会存在重复版本的 B 被安装，这两个重复安装的 B 就叫依赖分身。而且虽然看起来模块 C 和 E 都依赖 B@2.0，但其实引用的不是同一个 B，假设 B 在导出之前做了一些缓存或者副作用，那么使用者的项目就会因此而出错。

yarn

2016 年，yarn 发布，yarn 也采用扁平化 node_modules 结构。它的出现是为了解决 npm v3 几个最为迫在眉睫的问题：依赖安装速度慢，不确定性。

提升安装速度

在 npm 中安装依赖时，安装任务是串行的，会按包顺序逐个执行安装，这意味着它会等待一个包完全安装，然后再继续下一个。为了加快包安装速度，yarn 采用了并行操作，在性能上有显著的提高。而且在缓存机制上，yarn 会将每个包缓存在磁盘上，在下一次安装这个包时，可以脱离网络实现从磁盘离线安装。

lockfile 解决不确定性

yarn 更大的贡献是发明了 yarn.lock。在依赖安装时，会根据 package.josn 生成一份 yarn.lock 文件。 lockfile 里记录了依赖，以及依赖的子依赖，依赖的版本，获取地址与验证模块完整性的 hash。即使是不同的安装顺序，相同的依赖关系在任何的环境和容器中，都能得到稳定的 node_modules 目录结构，保证了依赖安装的确定性。所以 yarn 在出现时被定义为快速、安全、可靠的依赖管理。而 npm 在一年后的 v5 才发布了 package-lock.json。

与 npm 一样的弊端

yarn 依然和 npm 一样是扁平化的 node_modules 结构，没有解决幽灵依赖和依赖分身问题。

pnpm

pnpm - performant npm，在 2017 年正式发布，定义为快速的，节省磁盘空间的包管理工具，开创了一套新的依赖管理机制，成为了包管理的后起之秀。

内容寻址存储 CAS

与依赖提升和扁平化的 node_modules 不同，pnpm 引入了另一套依赖管理策略：内容寻址存储。该策略会将包安装在系统的全局 store 中，依赖的每个版本只会在系统中安装一次。在引用项目 node_modules 的依赖时，会通过硬链接与符号链接在全局 store 中找到这个文件。为了实现此过程，node_modules 下会多出 .pnpm 目录，而且是非扁平化结构。

硬链接 Hard link：硬链接可以理解为源文件的副本，项目里安装的其实是副本，它使得用户可以通过路径引用查找到全局 store 中的源文件，而且这个副本根本不占任何空间。同时，pnpm 会在全局 store 里存储硬链接，不同的项目可以从全局 store 寻找到同一个依赖，大大地节省了磁盘空间。
符号链接 Symbolic link：也叫软连接，可以理解为快捷方式，pnpm 可以通过它找到对应磁盘目录下的依赖地址。

还是使用上面 A，B，C 模块的示例，使用 pnpm 安装依赖后 node_modules 结构如下：

node_modules
├── .pnpm
│   ├── A@1.0.0
│   │   └── node_modules
│   │       ├── A => <store>/A@1.0.0
│   │       └── B => ../../B@1.0.0
│   ├── B@1.0.0
│   │   └── node_modules
│   │       └── B => <store>/B@1.0.0
│   ├── B@2.0.0
│   │   └── node_modules
│   │       └── B => <store>/B@2.0.0
│   └── C@1.0.0
│       └── node_modules
│           ├── C => <store>/C@1.0.0
│           └── B => ../../B@2.0.0
│
├── A => .pnpm/A@1.0.0/node_modules/A
└── C => .pnpm/C@1.0.0/node_modules/C

<store>/xxx 开头的路径是硬链接，指向全局 store 中安装的依赖。其余的是符号链接，指向依赖的快捷方式。 pnpm 官方图片也清晰地解释了这套机制：

这套全新的机制设计地十分巧妙，不仅兼容 node 的依赖解析，同时也解决了：

幽灵依赖问题：只有直接依赖会平铺在 node_modules 下，子依赖不会被提升，不会产生幽灵依赖。
依赖分身问题：相同的依赖只会在全局 store 中安装一次。项目中的都是源文件的副本，几乎不占用任何空间，没有了依赖分身。

同时，由于链接的优势，pnpm 的安装速度在大多数场景都比 npm 和 yarn 快 2 倍，节省的磁盘空间也更多。但也存在一些弊端：

由于 pnpm 创建的 node_modules 依赖软链接，因此在不支持软链接的环境中，无法使用 pnpm，比如 Electron 应用。
因为依赖源文件是安装在 store 中，调试依赖或 patch-package 给依赖打补丁也不太方便，可能会影响其他项目。

yarn Plug’n’Play

2020 年 1 月，yarn v2 发布，也叫 yarn berry（v1 叫 yarn classic）。它是对 yarn 的一次重大升级，其中一项重要更新就是 Plug’n’Play（Plug'n'Play = Plug and Play = PnP，即插即用）。 npm 与 yarn 的依赖安装与依赖解析都涉及大量的文件 I/O，效率不高。开发 Plug’n’Play 最直接的原因就是依赖引用慢，依赖安装慢。

抛弃 node_modules

无论是 npm 还是 yarn，都具备缓存的功能，大多数情况下安装依赖时，其实是将缓存中的相关包复制到项目目录中 node_modules 里。而 yarn PnP 则不会进行拷贝这一步，而是在项目里维护一张静态映射表 pnp.cjs。 pnp.cjs 会记录依赖在缓存中的具体位置，所有依赖都存在全局缓存中。同时自建了一个解析器，在依赖引用时，帮助 node 从全局缓存目录中发现依赖，而不是查找 node_modules。这样就避免了大量的 I/O 操作同时项目目录也不会有 node_modules 目录生成，同版本的依赖在全局也只会有一份，依赖的安装速度和解析速度都有较大提升。 pnpm 在 2020 年底的 v5.9 也支持了 PnP。

脱离 node 生态

pnp 比较明显的缺点是脱离了 node 生态。

因为使用 PnP 不会再有 node_modules 了，但是 Webpack，Babel 等各种前端工具都依赖 node_modules。虽然很多工具比如 pnp-webpack-plugin 已经在解决了，但难免会有兼容性风险。
PnP 自建了依赖解析器，所有的依赖引用都必须由解析器执行，因此只能通过 yarn 命令来执行 node 脚本。

总结

目前还没有完美的依赖管理方案，可以看到在依赖管理的发展过程中，出现了：

不同的 node_modules 结构，有嵌套，扁平，甚至没有 node_modules，不同的结构也伴随着兼容与安全问题。
不同的依赖存储方式来节约磁盘空间，提升安装速度。
每种管理器都伴随新的工具和命令，不同程度的可配置性和扩展性，影响开发者体验。