细品Npm 依赖处理的进化史（npm开发依赖生产依赖）

wxin55 2024-11-08 14:39 12 浏览 0 评论

作者：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 AF，可以想象，将不会出现模块冗余的情况。这说明：模块安装顺序可能影响 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 在设计时的确是抓住了很多细小的点去改善使用体验。

细品Npm 依赖处理的进化史（npm开发依赖生产依赖）

依赖地狱

依赖共享与冲突

推荐Vue学习资料文章：

相关推荐

取消回复欢迎你发表评论:

写给新手|头条文章如何排版更美观?电脑端教程

「基本功」前端安全系列之二:如何防止CSRF攻击?

MySQL InnoDB乐观锁，悲观锁(共享锁|排它锁)，行锁表锁及死锁

如何应用策略设计模式分离JDBC数据库连接中的外部环境信息

同一套网络直播源，为什么别人能用自己却用不了?

JavaScript 实现点击/关闭全屏（怎么关闭javascript弹出框）

视频讲解学员信息管理系统升级版（学员管理系统培训机构）

字符串:听说你对KMP还有这些疑问?

深入细聊前端下载总结「干货」（前端软件下载）

黑马程序员:IT技术学习线路图免费任性分享

细品Npm 依赖处理的进化史（npm开发依赖生产依赖）

依赖地狱

依赖共享与冲突

推荐Vue学习资料文章：

相关推荐

取消回复欢迎 你 发表评论:

写给新手|头条文章如何排版更美观?电脑端教程

「基本功」前端安全系列之二:如何防止CSRF攻击?

MySQL InnoDB乐观锁，悲观锁(共享锁|排它锁)，行锁表锁及死锁

如何应用策略设计模式分离JDBC数据库连接中的外部环境信息

同一套网络直播源，为什么别人能用自己却用不了?

JavaScript 实现点击/关闭全屏（怎么关闭javascript弹出框）

视频讲解学员信息管理系统升级版（学员管理系统 培训机构）

字符串:听说你对KMP还有这些疑问?

深入细聊前端下载总结「干货」（前端软件下载）

黑马程序员:IT技术学习线路图免费任性分享

取消回复欢迎你发表评论:

视频讲解学员信息管理系统升级版（学员管理系统培训机构）