我要成为node_modules大师!(一):包管理器选择,依赖关系分析
好家伙1.npm曾经的一些问题
1. 依赖地狱（Dependency Hell）
[*]嵌套依赖结构：早期版本的 npm 采用嵌套的 node_modules 结构，依赖层级极深，容易导致路径过长问题（尤其在 Windows 上），甚至触发文件系统限制。
[*]版本冲突：依赖的版本管理不够严格，容易出现“同一个包多个版本”共存的情况，导致项目体积膨胀或难以调试。
2. 性能问题
[*]安装速度慢：npm 的安装算法（尤其是 v3 之前）效率较低，依赖解析和下载时间较长。
[*]全局锁问题：npm 的锁文件（package-lock.json）设计曾被诟病与其他工具（如 Yarn）不兼容，且早期版本存在锁文件冲突问题。
3. 安全性历史问题
[*]依赖链风险：npm 允许依赖包自动安装任意子依赖，曾引发多起安全事件（例如 event-stream 恶意包注入事件）。
[*]权限问题：过去 npm 的包发布机制容易被滥用，出现过“包名抢注”（squatting）或低质量包泛滥的情况。
4. 设计哲学争议
[*]集中式 registry：npm 的官方 registry 是单点故障，一旦宕机（如 2020 年的服务中断），全球开发者受影响。
[*]语义化版本（SemVer）的滥用：许多包过度依赖 ^ 或 ~ 版本范围，导致不同环境安装的依赖版本不一致，可能引发意外问题。
5. 竞争对手的对比
[*]Yarn 的冲击：Yarn 在 2016 年推出后，凭借离线缓存、并行安装、更稳定的锁文件等特性，直接暴露了 npm 的短板。
[*]pnpm 的改进：pnpm 通过硬链接和符号链接优化存储空间和安装速度，进一步凸显了 npm 的冗余问题。
尽管如此
对于大多数普通项目，npm 已足够稳定，尤其是新版（v7+）吸收了 Yarn 和 pnpm 的优点。
2.包管理工具
npm官方默认，兼容性无敌Yarn稳定可靠，锁文件严谨pnpm省空间、快、无依赖冲突Bun宇宙最快，All-in-One
3.具体的依赖关系实例分析
现在 有两个项目,
项目1,依赖需求: a,b,c a依赖于b,c , c无依赖依赖
项目2.依赖需求: a,b,c,d a依赖于b,c , c依赖于d ,d依赖于b
这是两个典型项目,
第一个,代表直接依赖
第二个,代表嵌套依赖
现在我分别使用npm,yarn,pnpm,bun,
我们分别分析器其node_modules文件夹结构,以及package文件,和lock文件
3.1.第一个项目非常简单
安装结果对比
包管理器node_modules 结构锁文件格式npm扁平化（hoisting）:
- a, b, c（顶层）
- a/node_modules 无嵌套（依赖已提升）package-lock.json（嵌套结构，标记依赖来源）Yarn类似 npm 的扁平化:
- a, b, c（顶层）
- 无重复依赖yarn.lock（扁平列表，记录所有依赖的精确版本）pnpm隔离结构:
- 顶层只有 a, b, c（符号链接）
- 真实依赖存储在 ~/.pnpm-store，通过硬链接引用pnpm-lock.yaml（内容寻址，记录依赖的存储路径）Bun类似 pnpm 的硬链接优化:
- 扁平化但共享依赖存储
- 依赖通过硬链接复用bun.lockb（二进制锁文件，记录依赖树和哈希）
3.2.我们重点关注第二个项目
看看各家工具如何处理嵌套依赖
包管理器node_modules 结构关键区别npm扁平化 + 部分嵌套:
- a, b, c, d（顶层）
- 如果 b 有多个版本，低版本会嵌套在 d/node_modulespackage-lock.json 会标记 d 的 b 是否嵌套Yarn完全扁平化:
- a, b, c, d（顶层）
- 若版本冲突，Yarn 会选择一个版本，可能导致问题yarn.lock 会记录所有依赖的解析版本pnpm严格隔离:
- a, b, c, d（顶层符号链接）
- c 和 d 的 b 不会冲突，各自引用正确版本pnpm-lock.yaml 会记录每个包的独立存储路径Bun类似 pnpm:
- 共享存储 + 硬链接
- 依赖版本冲突时，Bun 会优先兼容bun.lockb 会优化存储，避免重复
来看示例图:
(1)NPM
node_modules
<strong>node_modules/
├── a/ # a@1.0.0
│ └── package.json # 依赖: b, c
├── b/ # b@1.0.0 (被 a 和 d 依赖)
├── c/ # c@1.0.0
│ └── package.json # 依赖: d
├── d/ # d@1.0.0
│ └── package.json # 依赖: b
└── .bin/ # 可执行文件（如果有）</strong>锁文件
package-lock.json
<strong>{
"name": "project2",
"version": "1.0.0",
"lockfileVersion": 2,
"requires": true,
"packages": {
"node_modules/a": {
"version": "1.0.0",
"dependencies": { "b": "^1.0.0", "c": "^1.0.0" }
},
"node_modules/b": { "version": "1.0.0" },
"node_modules/c": {
"version": "1.0.0",
"dependencies": { "d": "^1.0.0" }
},
"node_modules/d": {
"version": "1.0.0",
"dependencies": { "b": "^1.0.0" }
}
}
}</strong>(2)Yarn
node_modules
<strong>node_modules/
├── a/ # a@1.0.0
│ └── package.json # 依赖: b, c
├── b/ # b@1.0.0 (提升到顶层)
├── c/ # c@1.0.0
│ └── package.json # 依赖: d
├── d/ # d@1.0.0
│ └── package.json # 依赖: b
└── .bin/</strong>锁文件
yarn.lock
<strong># THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
a@1.0.0:
version "1.0.0"
dependencies:
b "^1.0.0"
c "^1.0.0"
b@1.0.0:
version "1.0.0"
c@1.0.0:
version "1.0.0"
dependencies:
d "^1.0.0"
d@1.0.0:
version "1.0.0"
dependencies:
b "^1.0.0"</strong>(3)pnpm
node_modules
<strong>node_modules/
├── a -> .pnpm/a@1.0.0/node_modules/a # 符号链接
├── b -> .pnpm/b@1.0.0/node_modules/b
├── c -> .pnpm/c@1.0.0/node_modules/c
├── d -> .pnpm/d@1.0.0/node_modules/d
└── .pnpm/
├── a@1.0.0/
│ └── node_modules/
│ ├── a # a 的真实文件
│ ├── b -> ../../b@1.0.0/node_modules/b# 硬链接
│ └── c -> ../../c@1.0.0/node_modules/c
├── c@1.0.0/
│ └── node_modules/
│ ├── c # c 的真实文件
│ └── d -> ../../d@1.0.0/node_modules/d
├── d@1.0.0/
│ └── node_modules/
│ ├── d # d 的真实文件
│ └── b -> ../../b@1.0.0/node_modules/b# 硬链接
└── b@1.0.0/
└── node_modules/
└── b # b 的真实文件</strong>锁文件
pnpm-lock.yaml
<strong>lockfileVersion: 5.4
dependencies:
a:
specifier: 1.0.0
version: 1.0.0
dependencies:
b: 1.0.0
c: 1.0.0
b:
specifier: 1.0.0
version: 1.0.0
c:
specifier: 1.0.0
version: 1.0.0
dependencies:
d: 1.0.0
d:
specifier: 1.0.0
version: 1.0.0
dependencies:
b: 1.0.0</strong>(4)bun
<strong>node_modules/
├── a/ # a@1.0.0 (硬链接到全局存储)
├── b/ # b@1.0.0 (硬链接)
├── c/ # c@1.0.0
├── d/ # d@1.0.0
└── .bin/</strong>锁文件
bun.lockb
为二进制
总结,
特性npmYarnpnpmBun依赖结构扁平化（可能嵌套冲突）完全扁平化（可能版本冲突）隔离 + 硬链接（无冲突）扁平化 + 硬链接优化安装速度慢较快最快（复用存储）极快（内置优化）磁盘占用高（每个项目独立存储）较高极低（全局共享存储）低（共享存储）锁文件格式package-lock.json（嵌套）yarn.lock（扁平列表）pnpm-lock.yaml（内容寻址）bun.lockb（二进制高效）幻影依赖严重（依赖提升）存在无（严格隔离）较少（但比 pnpm 宽松）
4.一个问题
对于项目2提出一个新的情况
假设项目本身依赖的b包为1.0.0
d包依赖的b包版本为:2.0.0
node_modules和锁文件会发生什么?
<strong>node_modules/
├── a/ # a@1.0.0
│ └── package.json # 依赖: b@1.0.0, c@1.0.0
├── b/ # b@1.0.0 (被提升到顶层)
├── c/ # c@1.0.0
│ └── package.json # 依赖: d@1.0.0
├── d/ # d@1.0.0
│ ├── node_modules/
│ │ └── b/ # b@2.0.0 (嵌套)
│ └── package.json # 依赖: b@2.0.0
└── .bin/</strong>
由于依赖提升,所以b包版本1.0.0(先遇到)于是,被提升到顶层
npm 会尽量将依赖提升到顶层，但同一包的不同版本只能提升一个，其余版本会嵌套。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]