npm 前端包管理器探究前言npm1. npm v1/v2 依赖嵌套

80 阅读 0 评论 53 点赞

我是靠谱客的博主风趣超短裙，最近开发中收集的这篇文章主要介绍npm 前端包管理器探究前言npm1. npm v1/v2 依赖嵌套，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

前言

npm是Node.JS的包管理工具，除此之外，社区有一些类似的包管理工具如yarn、pnpm和cnpm，以及集团内部使用的tnpm。我们在项目开发过程中通常使用以上主流包管理器生成node_modules目录安装依赖并进行依赖管理。本文主要探究前端包管理器的依赖管理原理，希望对读者有所帮助。

npm

当我们执行 npm install 命令后，npm会帮我们下载对应依赖包并解压到本地缓存，然后构造node_modules 目录结构，写入依赖文件。那么，对应的包在node_modules目录内部是怎样的结构呢，npm主要经历了以下几次变化。

1. npm v1/v2 依赖嵌套

npm最早的版本中使用了很简单的嵌套模式进行依赖管理。比如我们在项目中依赖了A模块和C模块，而A模块和C模块依赖了不同版本的B模块，此时生成的node_modules目录如下：

依赖地狱（Dependency Hell）

可以看到这种是嵌套的node_modules结构，每个模块的依赖下面还会存在一个 node_modules 目录来存放模块依赖的依赖。这种方式虽然简单明了，但存在一些比较大的问题。如果我们在项目中增加一个同样依赖2.0版本B的模块D，此时生成的node_modules目录便会如下所示。虽然模块A、D依赖同一个版本B，但B却重复下载安装了两遍，造成了重复的空间浪费。这便是依赖地狱问题。

node_modules
├── A@1.0.0
│   └── node_modules
│       └── B@1.0.0
├── C@1.0.0
│   └── node_modules
│       └── B@2.0.0
└── D@1.0.0
    └── node_modules
        └── B@1.0.0

一些著名的梗图：

2、npm v3 扁平化

npm v3完成重写了依赖安装程序，npm3通过扁平化的方式将子依赖项安装在主依赖项所在的目录中（hoisting提升），以减少依赖嵌套导致的深层树和冗余。此时生成的node_modules目录如下：

为了确保模块的正确加载，npm也实现了额外的依赖查找算法，核心是递归向上查找node_modules。在安装新的包时，会不停往上级node_modules中查找。如果找到相同版本的包就不会重新安装，在遇到版本冲突时才会在模块下的 node_modules 目录下存放该模块子依赖，解决了大量包重复安装的问题，依赖的层级也不会太深。

扁平化的模式解决了依赖地狱的问题，但也带来了额外的新问题。

幽灵依赖（Phantom dependency）

幽灵依赖主要发生某个包未在package.json中定义，但项目中依然可以引用到的情况下。考虑之前的案例，它的package.json如下图所示。

在index.js中我们可以直接require A，因为在package.json声明了该依赖，但是，我们require B也是可以正常工作的。

var A = require('A');
var B = require('B'); // ???

因为B是A的依赖项，在安装过程中，npm会将依赖B平铺到node_modules下，因此require函数可以查找到它。但这可能会导致意想不到的问题：

依赖不兼容：my-library库中并没有声明依赖B的版本，因此B的major更新对于SemVer体系是完全合法的，这就导致其他用户安装时可能会下载到与当前依赖不兼容的版本。
依赖缺失：我们也可以直接引用项目中devDepdency的子依赖，但其他用户安装时并不会devDepdency，这就可能导致运行时会立刻报错。

多重依赖（doppelgangers）

考虑在项目中继续引入的依赖2.0版本B的模块D与而1.0版本B的模块E，此时无论是把B 2.0还是1.0提升放在顶层，都会导致另一个版本存在重复的问题，比如这里重复的2.0。此时就会存在以下问题：

破坏单例模式：模块C、D中引入了模块B中导出的一个单例对象，即使代码里看起来加载的是同一模块的同一版本，但实际解析加载的是不同的module，引入的也是不同的对象。如果同时对该对象进行副作用操作，就会产生问题。
types冲突：虽然各个package的代码不会相互污染，但是他们的types仍然可以相互影响，因此版本重复可能会导致全局的types命名冲突。

不确定性（Non-Determinism）

在前端包管理的背景下，确定性指在给定package.json下，无论在何种环境下执行npm install命令都能得到相同的node_modules目录结构。然而npm v3是不确定性的，它node_modules目录以及依赖树结构取决于用户安装的顺序。

考虑项目拥有以下依赖树结构，其npm install产生的node_modules目录结构如下图所示。

假设当用户使用npm手动升级了模块A到2.0版本，导致其依赖的模块B升级到了2.0版本，此时的依赖树结构如下。

此时完成开发，将项目部署至服务器，重新执行npm install，此时提升的子依赖B版本发生了变化，产生的node_modules目录结构将会与用户本地开发产生的结构不同，如下图所示。如果需要node_modules目录结构一致，就需要在package.json修改时删除node_modules结构并重新执行npm install。

3. npm v5 扁平化+lock

在npm v5中新增了package-lock.json。当项目有package.json文件并首次执行npm install安装后，会自动生成一个package-lock.json文件，该文件里面记录了package.json依赖的模块，以及模块的子依赖。并且给每个依赖标明了版本、获取地址和验证模块完整性哈希值。通过package-lock.json，保障了依赖包安装的确定性与兼容性，使得每次安装都会出现相同的结果。

一致性

考虑上文案例，初始时安装生成package-lock.json如左图所示，depedencies对象中列出的依赖都是提升的，每个依赖项中的requires对象中为子依赖项。此时更新A依赖到2.0版本，如右图所示，并不会改变提升的子依赖版本。因此重新生成的node_modules目录结构将不会发生变化。