依赖地狱

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

例如,当前项目有依赖的模块 A, B, A 又依赖于模块 C, D, B 又依赖于模块 C, E,此时,项目的 node_modules 目录结构如下:

1
2
3
4
5
6
7
8
9
10
root
└── node_modules
├── A
│ └── node_modules
│ ├── C
│ └── D
└── B
└── node_modules
├── C
└── E

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

  1. 依赖树的层级非常深。如果需要定位某依赖的依赖,很难找到该依赖的文件所在(例如,如果想定位模块 E,就不得不先知道他在依赖树中的位置);
  2. 不同的依赖树分支里,可能有大量实际上是同样版本的依赖(例如,A 目录下的 CB 目录下面的 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.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.0C@2.0.0 被分别依赖,鉴于模块在同一个 node_modules 目录中是按照模块名目录存放,因此这两个版本没办法同时平铺在同一目录,因此,其中一个版本的 C 模块将会以 npm v2 的处理方式放入子 node_modules 目录中。

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

  1. 在空目录下,通过 npm install --save A@1.0.0 先安装 A。由于它和它的依赖在 node_modules 下都不会产生冲突,因此能够直接平铺的放入其中。此时目录结构如下:

    1
    2
    3
    4
    5
    root
    └── node_modules
    ├── A@1.0.0
    ├── C@1.0.0
    └── D@0.6.5
  2. 继续通过 npm install --save B@1.0.0 安装 BB 自身以及它的依赖 E 也没有冲突,直接平铺放入 node_modules 下;但是 B 的另一依赖 C@2.0.0 因为 C@1.0.0 已经存在了,出现了版本冲突,它将不得不被放置于 B 目录下的 node_modules 中。此时目录结构如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    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 内的文件结构

  3. 在上面的先 AB 的情形下,继续安装依赖 F@1.0.0,它拥有依赖 C@2.0.0G@1.0.0。类似的,它的依赖 C@2.0.0 因为版本冲突,不得不被放置于 Fnode_modules 中。此时目录结构如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    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 内的文件数量

  4. 假设模块 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,因为顶层目录中没有版本冲突发生。

    此时的目录结构如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    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 之后,目录结构如下:

    1
    2
    3
    4
    5
    6
    7
    8
    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 操作:

1
2
3
4
$ 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 在设计时得确是抓住了很多细小的点去改善使用体验。

参考