【NPM】674- Npm 依赖处理的进化史

前端自习课

共 3390字,需浏览 7分钟

 ·

2020-08-03 17:21



作者:aprilandjan

来源:http://aprilandjan.github.io/

依赖地狱

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

例如,当前项目有依赖的模块 ABA 又依赖于模块 CDB 又依赖于模块 CE,此时,项目的 node_modules 目录结构如下:


root
└── node_modules
├── A
│ └── node_modules
│ ├── C
│ └── D
└── B
└── node_modules
├── C
└── E

可以想象,这样做的确能尽量保证每个模块自身的可用性。但是,当项目规模达到一定程度时,也会造成许多问题:

  1. 依赖树的层级非常深。如果需要定位某依赖的依赖,很难找到该依赖的文件所在(例如,如果想定位模块 E,就不得不先知道他在依赖树中的位置);
  2. 不同的依赖树分支里,可能有大量实际上是同样版本的依赖(例如,A 目录下的 C 和 B 目录下面的 C 如果版本一致,实际上完全一样);
  3. 安装时额外下载或拷贝了大量重复的资源,并且实际上也占用了大量的硬盘空间资源等(例如,C 模块在依赖目录中出现了两次);
  4. 安装速度慢,甚至因为目录层级太深导致文件路径太长的缘故,在 windows 系统下删除 node_modules 文件夹也可能失败!

正是因为这些问题的存在,彼时的 node_modules 又被叫做依赖地狱(Dependency Hell)

依赖共享与冲突

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

例如,当前项目有依赖的模块 A@1.0.0B@1.0.0A@1.0.0 依赖于模块 C@1.0.0D@0.6.5B@1.0.0 又依赖于模块 C@2.0.0E@1.0.3。注意,此时由于模块 C 的两个版本 C@1.0.0 和 C@2.0.0 被分别依赖,鉴于模块在同一个 node_modules 目录中是按照模块名目录存放,因此这两个版本没办法同时平铺在同一目录,因此,其中一个版本的 C 模块将会以 npm v2 的处理方式放入子 node_modules 目录中。

那么,应该是哪一个版本的 C 会被这样处理呢?考虑以下操作时序:

  1. 在空目录下,通过 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
  1. 继续通过 npm install \--save B@1.0.0 安装 BB 自身以及它的依赖 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 再安装 AC@1.0.0 将位于 A 目录下的 node_modules 中。这说明:模块的安装顺序可能影响 node_modules 内的文件结构

  1. 在上面的先 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 内的文件数量

  1. 假设模块 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




1. JavaScript 重温系列(22篇全)
2. ECMAScript 重温系列(10篇全)
3. JavaScript设计模式 重温系列(9篇全)
4. 正则 / 框架 / 算法等 重温系列(16篇全)
5. Webpack4 入门(上)|| Webpack4 入门(下)
6. MobX 入门(上) ||  MobX 入门(下)
7. 70+篇原创系列汇总

回复“加群”与大佬们一起交流学习~

点击“阅读原文”查看70+篇原创文章

点这,与大家一起分享本文吧~

浏览 25
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报