npm 依赖处理的进化史

依赖地狱

早期版本的npm(v2)管理依赖的方式并不复杂。它读取每个模块的依赖列表，并下载匹配版本的依赖模块到该模块目录内的node_modules文件夹下，如果该依赖还依赖其他的模块就继续下载该依赖的依赖到该依赖模块目录的node_modules文件夹下----如此递归执行下去，最终形成一颗庞大的依赖树。

问题:

1 依赖树的层级可能会非常深。如果要定位某依赖的依赖，很难找到该依赖的文件所在。

2 不同的依赖书分支中，可能有大量实际上是同版本的依赖

3 安装时额外下载或者拷贝了大量重复的资源。

4 安装速度慢，层级太深还会导致删除失败

正因为这些问题的存在，彼时的node_modules又被叫做依赖地狱。

依赖共享与冲突

在npm3版本之后，npm采用了更合理的昂是去解决之前的依赖地狱的问题。npm v3 尝试把依赖以及依赖的依赖都尽量的平铺在项目根目录下的node_modules文件夹下以共享使用；如果遇到因为需要的版本要求不一致导致冲突，没办法放在平铺目录下，回退到npm v2的处理方式，在该模块下的node_modules里存放冲突的模块。

模块的依赖是按顺序来安装的，所以模块安装顺序可能影响node_modules内的文件数量，demo:

如果先安装B,就会少一些文件。

如果后面A模板依赖的C模块需要升级到2.0，npm 会删除A和C，重新安装A模块，并在A模块的node_modules中存放C2.0，这样就又回到npm v2了；所幸npm提供了一个单独的命令 npm dedupe用以去掉类似情况下产生的冗余代码，在depude之后，目录结构如下：

 

 

 

参考 https://mp.weixin.qq.com/s/Uef1Ttr1PWqRpRSqZ7QpBw