npm

扁平的node_modules结构

比如项目依赖了A 和 C，而 A 和 C 依赖了不同版本的 B@1.0 和 B@2.0，D也依赖B@1.0, node_modules 结构如下：

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

C依赖的B@2.0因为版本号原因还放在C的node_modules下

幽灵依赖

幽灵以来是指在package.json中未定义的依赖，但项目中依然可以被引用到

比如上方我们package.json只安装了A和C

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

由于B在安装时被提升到了和A同样的级别，所以在项目中可以正常引用B

幽灵依赖是由依赖的声明丢失造成的，如果某天某个版本A依赖不在依赖B或者B版本发生了变化，那么就会造成依赖缺失和兼容性问题

依赖分身

假设继续再安装依赖 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 就叫 依赖分身

yarn

yarn也是用扁平化node_modules结构

提升安装速度

在npm安装依赖时，安装任务是串行的。这意味着需要等待一个结束再进行下一个

为了加快安装速度，yarn采用了并行操作。在缓存机制上，yarn会将每个包缓存再磁盘上，在下一次安装这个包时，可以脱离网络实现从磁盘离线安装。

与npm一样的弊端

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

pnpm

内容寻址存储

该策略会将包安装在系统的全局store中，依赖的每个版本只会在系统中安装一次

在引用项目node_modules的依赖时，会通过硬链接和软链接在全局store中找到这个文件。为了实现此过程，node_modules下会多出.pnpm目录，而且是非扁平化结构

• 硬链接：可以理解为源文件的副本，项目安装的其实是副本，它使得用户可以通过路径引用查到全局store中的源文件，而且这个副本根本不占任何空间。同时，pnpm会在全局store里存储硬链接，不同的项目可以从全局store寻到同一个依赖，大大的节省了磁盘空间

• 软链接：可以理解为快捷方式，pnpm可以通过找到它对应的磁盘目录下的依赖地址