各位靓仔靓女们，晚上好！我是你们的老朋友，今晚咱们聊聊 JavaScript 的依赖管理，特别是 NPM 和 pnpm 这两个家伙，以及它们是如何摆弄咱们的 node_modules 文件夹的。
开场白：依赖地狱的传说
话说江湖上流传着一个恐怖的传说，叫做“依赖地狱”。它描述的是当你的项目依赖越来越多，版本冲突越来越复杂，最终导致项目崩溃，程序员抱头痛哭的惨状。为了解决这个问题，各种包管理工具应运而生，其中 NPM 和 pnpm 就是两位响当当的人物。
第一回合：NPM，老大哥的策略
NPM (Node Package Manager)，作为 Node.js 的官方包管理工具，资历老，用户多，生态完善。它的策略可以用八个字概括：简单粗暴，直接安装。
1.1 NPM 的安装策略：深度优先，一棵大树
当咱们用 NPM 安装一个包时，它会遵循深度优先的原则，把这个包以及它的所有依赖都一股脑儿地安装到 node_modules 里面。如果不同的包依赖同一个包的不同版本，NPM 会毫不犹豫地把这些版本都安装进去。
咱们来看个例子：
// package.json
{
"name": "my-app",
"dependencies": {
"A": "1.0.0",
"B": "2.0.0"
}
}其中，包 A 依赖 [email protected]，包 B 依赖 [email protected]。
执行 npm install 之后，node_modules 的结构大概是这样：
node_modules/
├── A/
│ ├── index.js
│ └── node_modules/
│ └── C/
│ ├── index.js ([email protected])
│ └── package.json
├── B/
│ ├── index.js
│ └── node_modules/
│ └── C/
│ ├── index.js ([email protected])
│ └── package.json
└── C/
├── index.js ([email protected]) //顶层，扁平化安装
└── package.json注意，NPM 3+ 版本会尝试“扁平化”依赖树，尽可能地把依赖安装在顶层 node_modules 目录下，以减少重复安装。但是，遇到版本冲突时，还是会乖乖地把不同版本的依赖安装到各自依赖包的 node_modules 里面。
1.2 NPM 的优缺点：
| 优点 | 缺点 |
|---|---|
| 简单易用 | 占用空间大，因为重复安装依赖 |
| 生态系统完善 | 可能出现“幽灵依赖”（phantom dependencies）问题，即没有在 package.json 中声明的依赖也能使用 |
| 兼容性好 | 安装速度相对较慢 |
| 适用于小型简单项目 |
1.3 幽灵依赖：
幽灵依赖指的是你的项目代码中使用了某个包，但这个包并没有直接声明在 package.json 的 dependencies 中。之所以能使用，是因为这个包是某个依赖包的依赖，并且 NPM 扁平化安装时把它提升到了顶层 node_modules 目录。
这听起来好像挺方便，但其实是个隐患。因为一旦你升级了依赖包，或者换了包管理工具，这个幽灵依赖可能就消失了，导致你的代码报错。
第二回合：pnpm，后起之秀的妙招
pnpm (performant npm) 的出现，就是为了解决 NPM 的一些痛点。它的核心思想是：共享依赖，节省空间。
2.1 pnpm 的安装策略：内容寻址，硬链接和符号链接
pnpm 使用了一种叫做“内容寻址” (content-addressable) 的方式来管理依赖。简单来说，就是它会把每个版本的依赖都存储在一个全局的 store 里面，然后通过硬链接和符号链接的方式，把依赖链接到项目的 node_modules 目录。
这样做的好处是：
- 节省磁盘空间：相同的依赖只会被存储一次，无论多少个项目使用它。
- 安装速度快：因为大部分依赖都已经在 store 里面了，所以安装时只需要创建链接，不需要下载和复制文件。
- 避免幽灵依赖：pnpm 创建的
node_modules目录结构是严格的，只有在package.json中声明的依赖才能被访问到。
咱们再来看一个例子，还是用上面的 package.json：
// package.json
{
"name": "my-app",
"dependencies": {
"A": "1.0.0",
"B": "2.0.0"
}
}执行 pnpm install 之后，node_modules 的结构会是这样：
node_modules/
├── .pnpm/
│ ├── [email protected]/
│ │ └── node_modules/
│ │ └── A/ (实际的 [email protected] 代码)
│ ├── [email protected]/
│ │ └── node_modules/
│ │ └── B/ (实际的 [email protected] 代码)
│ └── [email protected]/
│ │ └── node_modules/
│ │ └── C/ (实际的 [email protected] 代码)
│ └── [email protected]/
│ └── node_modules/
│ └── C/ (实际的 [email protected] 代码)
├── A -> .pnpm/[email protected]/node_modules/A
├── B -> .pnpm/[email protected]/node_modules/B解释一下：
.pnpm目录是 pnpm 存放依赖的全局 store 的一个“镜像”。它里面包含了所有版本的依赖的实际代码。node_modules目录下，A和B都是符号链接，指向.pnpm目录下的对应依赖。
关键点：
- 只有直接声明在
package.json中的依赖，才会出现在node_modules的顶层目录。 - 依赖的依赖，不会被提升到顶层目录。
2.2 pnpm 的优缺点：
| 优点 | 缺点 |
|---|---|
| 节省磁盘空间 | node_modules 结构与 NPM 不同，可能导致一些工具或库不兼容（虽然这种情况越来越少） |
| 安装速度快 | 对于不熟悉 pnpm 的开发者来说，node_modules 目录的结构可能比较迷惑 |
| 避免幽灵依赖 | 需要学习一些 pnpm 特有的命令和配置 |
| 更好的安全性 | |
| 适用于大型复杂项目 |
2.3 硬链接 vs 符号链接：
- 硬链接 (hard link)：可以理解为给同一个文件起了多个名字。它们指向的是硬盘上的同一个 inode (索引节点)，因此它们共享相同的数据块。删除其中一个链接，不会影响其他链接和文件本身。
- 符号链接 (symbolic link)：也叫软链接 (soft link)，可以理解为 Windows 里面的快捷方式。它指向的是另一个文件或目录的路径。删除符号链接，不会影响目标文件或目录。但是，如果目标文件或目录被删除，符号链接就会失效。
pnpm 在 .pnpm 目录内部使用硬链接，在 node_modules 目录中使用符号链接。
第三回合：yarn，曾经的挑战者
Yarn 也是一个流行的包管理工具，它曾经试图挑战 NPM 的地位。它的主要特点是速度快和确定性构建。但是，在 NPM 和 pnpm 的不断发展下，Yarn 的优势已经不那么明显了。
Yarn 的安装策略和 NPM 类似，也是深度优先，一棵大树。但是，Yarn 使用了一种叫做“lockfile”的机制来保证依赖的确定性。
3.1 Yarn 的 lockfile：锁定依赖版本
lockfile (通常是 yarn.lock 文件) 记录了项目中所有依赖及其子依赖的精确版本信息。当你执行 yarn install 时，Yarn 会优先读取 lockfile，按照 lockfile 中记录的版本安装依赖，而忽略 package.json 中指定的版本范围。
这样做的好处是：
- 保证不同环境下安装的依赖版本一致：避免因为依赖版本更新导致的问题。
- 提高安装速度：因为 Yarn 可以直接从缓存中读取 lockfile 中记录的依赖，而不需要重新解析
package.json。
3.2 Yarn 的优缺点：
| 优点 | 缺点 |
|---|---|
| 速度快 | 占用空间大，因为重复安装依赖 |
| 确定性构建 | 可能出现“幽灵依赖”问题 |
| 兼容性好 | 与 NPM 的安装策略类似，node_modules 结构也类似，因此兼容性问题较少 |
| 适用于各种规模的项目 |
第四回合：实战演练，代码说话
咱们来做一个简单的对比测试，看看 NPM 和 pnpm 在安装速度和磁盘空间占用上的差异。
4.1 测试项目：create-react-app
咱们选择 create-react-app 作为测试项目，因为它依赖比较多，比较有代表性。
4.2 测试环境：
- Node.js: v16.x
- NPM: v8.x
- pnpm: v6.x
- 操作系统: macOS
4.3 测试步骤：
-
创建一个新的
create-react-app项目：npx create-react-app my-app cd my-app -
分别使用 NPM 和 pnpm 安装依赖：
# 使用 NPM rm -rf node_modules package-lock.json time npm install # 使用 pnpm rm -rf node_modules pnpm-lock.yaml time pnpm install -
统计
node_modules目录的大小：du -sh node_modules
4.4 测试结果（仅供参考，不同环境下结果可能不同）：
| 包管理工具 | 安装时间 (秒) | node_modules 大小 (MB) |
|---|---|---|
| NPM | 60 | 300 |
| pnpm | 30 | 150 |
可以看到，在我们的测试环境下，pnpm 在安装速度和磁盘空间占用上都明显优于 NPM。
第五回合：总结与展望
| 特性 | NPM | pnpm | yarn |
|---|---|---|---|
| 安装策略 | 深度优先，一棵大树 | 内容寻址，硬链接和符号链接 | 深度优先，一棵大树 |
| 磁盘空间占用 | 较高，重复安装依赖 | 较低，共享依赖 | 较高，重复安装依赖 |
| 安装速度 | 相对较慢 | 较快 | 较快 |
| 幽灵依赖 | 可能存在 | 避免 | 可能存在 |
| 兼容性 | 较好 | 相对较差（但已逐渐改善） | 较好 |
| 适用场景 | 小型简单项目 | 大型复杂项目 | 各种规模的项目 |
| lockfile | package-lock.json |
pnpm-lock.yaml |
yarn.lock |
总的来说，NPM 依然是 JavaScript 世界的老大哥，生态系统完善，兼容性好。pnpm 作为一个后起之秀，凭借其节省空间和快速安装的优势，越来越受到开发者的青睐。Yarn 曾经是挑战者，现在仍然是一个不错的选择，特别是对于那些已经习惯使用 Yarn 的项目。
选择哪个包管理工具，取决于你的具体需求和偏好。如果你追求简单易用，NPM 是一个不错的选择。如果你追求节省空间和快速安装，pnpm 值得一试。如果你已经习惯使用 Yarn，并且对它的确定性构建特性情有独钟，那就继续用下去吧。
未来，包管理工具的发展趋势可能会更加注重性能、安全性和易用性。例如，可能会出现更加智能的依赖分析算法，可以更好地解决版本冲突问题。也可能会出现更加安全的包发布和分发机制，可以防止恶意代码的传播。
尾声：祝大家远离依赖地狱！
希望今天的分享对大家有所帮助。记住，选择合适的包管理工具，并养成良好的依赖管理习惯，可以帮助你远离依赖地狱，写出更加健壮和可靠的代码。
祝大家编码愉快！下次再见！