【NPM】674- Npm 依赖处理的进化史
共 3390字,需浏览 7分钟
·
2020-08-03 17:21
作者:aprilandjan
来源:http://aprilandjan.github.io/
依赖地狱
早期版本的的 npm (v2) 管理模块依赖的方式并不复杂。它读取每个模块的依赖列表,并下载匹配版本的依赖模块到该模块目录内的 node_modules
文件夹下;如果该依赖又依赖了其他的模块,会继续下载该依赖的依赖到该模块目录的 node_modules
文件夹下——如此递归执行下去,最终形成一颗庞大的依赖树。
例如,当前项目有依赖的模块 A
, B
, A
又依赖于模块 C
, D
, B
又依赖于模块 C
, E
,此时,项目的 node_modules
目录结构如下:
root
└── node_modules
├── A
│ └── node_modules
│ ├── C
│ └── D
└── B
└── node_modules
├── C
└── E
可以想象,这样做的确能尽量保证每个模块自身的可用性。但是,当项目规模达到一定程度时,也会造成许多问题:
依赖树的层级非常深。如果需要定位某依赖的依赖,很难找到该依赖的文件所在(例如,如果想定位模块 E
,就不得不先知道他在依赖树中的位置);不同的依赖树分支里,可能有大量实际上是同样版本的依赖(例如, A
目录下的C
和B
目录下面的C
如果版本一致,实际上完全一样);安装时额外下载或拷贝了大量重复的资源,并且实际上也占用了大量的硬盘空间资源等(例如, C
模块在依赖目录中出现了两次);安装速度慢,甚至因为目录层级太深导致文件路径太长的缘故,在 windows 系统下删除 node_modules
文件夹也可能失败!
正是因为这些问题的存在,彼时的 node_modules
又被叫做依赖地狱(Dependency Hell)
。
依赖共享与冲突
在 npm v3 版本之后,npm 采用了更合理的方式去解决之前的依赖地域的问题。npm v3 尝试把依赖以及依赖的依赖都尽量的平铺在项目根目录下的 node_modules
文件夹下以共享使用;如果遇到因为需要的版本要求不一致导致冲突,没办法放在平铺目录下的,回退到 npm v2 的处理方式,在该模块下的 node_modules
里存放冲突的模块。
例如,当前项目有依赖的模块 A@1.0.0
, B@1.0.0
, A@1.0.0
依赖于模块 C@1.0.0
, D@0.6.5
, B@1.0.0
又依赖于模块 C@2.0.0
, E@1.0.3
。注意,此时由于模块 C
的两个版本 C@1.0.0
和 C@2.0.0
被分别依赖,鉴于模块在同一个 node_modules
目录中是按照模块名目录存放,因此这两个版本没办法同时平铺在同一目录,因此,其中一个版本的 C
模块将会以 npm v2 的处理方式放入子 node_modules
目录中。
那么,应该是哪一个版本的 C
会被这样处理呢?考虑以下操作时序:
在空目录下,通过 npm install \--save A@1.0.0
先安装A
。由于它和它的依赖在node_modules
下都不会产生冲突,因此能够直接平铺的放入其中。此时目录结构如下:
root
└── node_modules
├── A@1.0.0
├── C@1.0.0
└── D@0.6.5
继续通过 npm install \--save B@1.0.0
安装B
。B
自身以及它的依赖E
也没有冲突,直接平铺放入node_modules
下;但是B
的另一依赖C@2.0.0
因为C@1.0.0
已经存在了,出现了版本冲突,它将不得不被放置于B
目录下的node_modules
中。此时目录结构如下:
root
└── node_modules
├── A@1.0.0
├── B@1.0.0
│ └── node_modules
│ └── C@2.0.0
├── C@1.0.0
├── D@0.6.5
└── E@1.0.3
通过以上分析可知,如果先安装 B
再安装 A
,C@1.0.0
将位于 A
目录下的 node_modules
中。这说明:模块的安装顺序可能影响 node_modules
内的文件结构。
在上面的先 A
后B
的情形下,继续安装依赖F@1.0.0
,它拥有依赖C@2.0.0
和G@1.0.0
。类似的,它的依赖C@2.0.0
因为版本冲突,不得不被放置于F
的node_modules
中。此时目录结构如下:
root
└── node_modules
├── A@1.0.0
├── B@1.0.0
│ └── node_modules
│ └── C@2.0.0
├── C@1.0.0
├── D@0.6.5
├── E@1.0.3
└── F@1.0.0
└── node_modules
└── C@2.0.0
观察发现,模块 C@2.0.0
还是出现了冗余。然而,假如安装的顺序是 B
A
F
,可以想象,将不会出现模块冗余的情况。这说明:模块安装顺序可能影响 node_modules
内的文件数量。
假设模块
A
的新版本A@2.0.0
,它不再依赖C@1.0.0
而是C@2.0.0
, 现在在以上项目中执行npm install A@2
,将会发生以下操作:此时的目录结构如下:
移除模块 A@1.0.0
;移除模块 C@1.0.0
,因为没有其他的模块依赖它;添加模块 A@2.0.0
;在顶层 node_modules
中安装模块C@2.0.0
,因为顶层目录中没有版本冲突发生。
root
└── node_modules
├── A@2.0.0
├── B@1.0.0
│ └── node_modules
│ └── C@2.0.0
├── C@2.0.0
├── D@0.6.5
├── E@1.0.3
└── F@1.0.0
└── node_modules
└── C@2.0.0
可以发现,目录中冗余了多个 C@2.0.0
模块!所幸 npm 提供了一个单独的命令 npm dedupe
用以去掉类似情况下产生的冗余拷贝。在 dedupe 之后,目录结构如下:
root
└── node_modules
├── A@2.0.0
├── B@1.0.0
├── C@2.0.0
├── D@0.6.5
├── E@1.0.3
└── F@1.0.0
顺便提一句:yarn
在安装依赖时会自动执行 dedupe
操作:
$ yarn dedupe
yarn dedupe v1.17.3
error The dedupe command isn't necessary. `yarn install` will already dedupe.
info Visit https://yarnpkg.com/en/docs/cli/dedupe for documentation about this command.
可见 yarn 在设计时的确是抓住了很多细小的点去改善使用体验。
参考
https://npm.github.io/how-npm-works-docs/index.html
回复“加群”与大佬们一起交流学习~
点击“阅读原文”查看70+篇原创文章