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_modules |
package-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
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/ # 可执行文件（如果有）
锁文件
package-lock.json
{ "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" } } } }
(2)Yarn
node_modules
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/
锁文件
yarn.lock
# 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"
(3)pnpm
node_modules
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 的真实文件
锁文件
pnpm-lock.yaml
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
(4)bun
node_modules/ ├── a/ # a@1.0.0 (硬链接到全局存储) ├── b/ # b@1.0.0 (硬链接) ├── c/ # c@1.0.0 ├── d/ # d@1.0.0 └── .bin/
锁文件
bun.lockb
为二进制
总结,
| 特性 | npm | Yarn | pnpm | Bun |
|---|---|---|---|---|
| 依赖结构 | 扁平化（可能嵌套冲突） | 完全扁平化（可能版本冲突） | 隔离 + 硬链接（无冲突） | 扁平化 + 硬链接优化 |
| 安装速度 | 慢 | 较快 | 最快（复用存储） | 极快（内置优化） |
| 磁盘占用 | 高（每个项目独立存储） | 较高 | 极低（全局共享存储） | 低（共享存储） |
| 锁文件格式 | package-lock.json（嵌套） |
yarn.lock（扁平列表） |
pnpm-lock.yaml（内容寻址） |
bun.lockb（二进制高效） |
| 幻影依赖 | 严重（依赖提升） | 存在 | 无（严格隔离） | 较少（但比 pnpm 宽松） |
4.一个问题
对于项目2提出一个新的情况
假设项目本身依赖的b包为1.0.0
d包依赖的b包版本为:2.0.0
node_modules和锁文件会发生什么?
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/
由于依赖提升,所以b包版本1.0.0(先遇到)于是,被提升到顶层
npm 会尽量将依赖提升到顶层，但同一包的不同版本只能提升一个，其余版本会嵌套。
