依赖地狱

早期版本的的 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 目录下的 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.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 会被这样处理呢？考虑以下操作时序：

  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 安装 B。B 自身以及它的依赖 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 再安装 A，C@1.0.0 将位于 A 目录下的 node_modules 中。这说明：模块的安装顺序可能影响 node_modules 内的文件结构。

  3. 在上面的先 A 后 B 的情形下，继续安装依赖 F@1.0.0，它拥有依赖 C@2.0.0 和 G@1.0.0。类似的，它的依赖 C@2.0.0 因为版本冲突，不得不被放置于 F 的 node_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 在设计时得确是抓住了很多细小的点去改善使用体验。

参考