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

作者：aprilandjan

​

依赖地狱

早期版本的的 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      

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

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​

​ 里存放冲突的模块。

例如，当前项目有依赖的模块 ​

​[email protected]​

​​, ​

​[email protected]​

​​, ​

​[email protected]​

​​ 依赖于模块 ​

​[email protected]​

​​, ​

​[email protected]​

​​, ​

​[email protected]​

​​ 又依赖于模块 ​

​[email protected]​

​​, ​

​[email protected]​

​​。注意，此时由于模块 ​

​C​

​​ 的两个版本 ​

​[email protected]​

​​ 和 ​

​[email protected]​

​​ 被分别依赖，鉴于模块在同一个 ​

​node_modules​

​​ 目录中是按照模块名目录存放，因此这两个版本没办法同时平铺在同一目录，因此，其中一个版本的 ​

​C​

​​ 模块将会以 npm v2 的处理方式放入子 ​

​node_modules​

​ 目录中。

那么，应该是哪一个版本的 ​

​C​

​ 会被这样处理呢？考虑以下操作时序：

1. 在空目录下，通过​

   ​npm install \--save [email protected]​

   ​ 先安装 ​

   ​A​

   ​。由于它和它的依赖在 ​

   ​node_modules​

   ​ 下都不会产生冲突，因此能够直接平铺的放入其中。此时目录结构如下：

root
└── node_modules
 ├── [email protected]
 ├── [email protected]
 └── [email protected]      

1. 继续通过​

   ​npm install \--save [email protected]​

   ​ 安装 ​

   ​B​

   ​。​

   ​B​

   ​ 自身以及它的依赖 ​

   ​E​

   ​ 也没有冲突，直接平铺放入 ​

   ​node_modules​

   ​ 下；但是 ​

   ​B​

   ​ 的另一依赖 ​

   ​[email protected]​

   ​ 因为 ​

   ​[email protected]​

   ​ 已经存在了，出现了版本冲突，它将不得不被放置于 ​

   ​B​

   ​ 目录下的 ​

   ​node_modules​

   ​ 中。此时目录结构如下：

root
└── node_modules
 ├── [email protected]
 ├── [email protected]
 │   └── node_modules
 │       └── [email protected]
 ├── [email protected]
 ├── [email protected]
 └── [email protected]      

通过以上分析可知，如果先安装 ​

​B​

​​ 再安装 ​

​A​

​​，​

​[email protected]​

​​ 将位于 ​

​A​

​​ 目录下的 ​

​node_modules​

​ 中。这说明：模块的安装顺序可能影响 ​

​node_modules​

​ 内的文件结构。

1. 在上面的先​

   ​A​

   ​ 后 ​

   ​B​

   ​ 的情形下，继续安装依赖 ​

   ​[email protected]​

   ​，它拥有依赖 ​

   ​[email protected]​

   ​ 和 ​

   ​[email protected]​

   ​。类似的，它的依赖 ​

   ​[email protected]​

   ​ 因为版本冲突，不得不被放置于 ​

   ​F​

   ​ 的 ​

   ​node_modules​

   ​中。此时目录结构如下：

root
└── node_modules
 ├── [email protected]
 ├── [email protected]
 │   └── node_modules
 │       └── [email protected]
 ├── [email protected]
 ├── [email protected]
 ├── [email protected]
 └── [email protected]
     └── node_modules
         └── [email protected]      

观察发现，模块 ​

​[email protected]​

​​ 还是出现了冗余。然而，假如安装的顺序是 ​

​B​

​​ ​

​A​

​​ ​

​F​

​，可以想象，将不会出现模块冗余的情况。这说明：模块安装顺序可能影响 ​

​node_modules​

​ 内的文件数量。

1. 假设模块​

   ​A​

   ​ 的新版本 ​

   ​[email protected]​

   ​，它不再依赖 ​

   ​[email protected]​

   ​ 而是 ​

   ​[email protected]​

   ​， 现在在以上项目中执行 ​

   ​npm install A@2​

   ​，将会发生以下操作：

   此时的目录结构如下：

• 移除模块​

  ​[email protected]​

  ​；
• 移除模块​

  ​[email protected]​

  ​，因为没有其他的模块依赖它；
• 添加模块​

  ​[email protected]​

  ​；
• 在顶层​

  ​node_modules​

  ​ 中安装模块 ​

  ​[email protected]​

  ​，因为顶层目录中没有版本冲突发生。

root
└── node_modules
 ├── [email protected]
 ├── [email protected]
 │   └── node_modules
 │       └── [email protected]
 ├── [email protected]
 ├── [email protected]
 ├── [email protected]
 └── [email protected]
     └── node_modules
         └── [email protected]      

可以发现，目录中冗余了多个 ​

​[email protected]​

​​ 模块！所幸 npm 提供了一个单独的命令 ​

​npm dedupe​

​用以去掉类似情况下产生的冗余拷贝。在 dedupe 之后，目录结构如下：

root
└── node_modules
 ├── [email protected]
 ├── [email protected]
 ├── [email protected]
 ├── [email protected]
 ├── [email protected]
 └── [email protected]      

顺便提一句：​

​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​​