简单探究npm相关机制 javascript前端npm

从这篇文章中能获得什么？

npm的安装机制，即在执行install命令时都做了什么事？
npm的缓存策略，这里做了简单介绍，没深入。
npm的依赖管理，即我们每次安装的依赖都是怎么在node_modules进行管理的？
lock文件究竟有什么用？我们到底需要吗？

如果大家对上面三点都很清楚，那就不用浪费太多时间，简单回顾一下就好。
如果不清楚的话可以沉下心看8分钟。
npm依赖安装机制首先我们来了解一下npm依赖安装的设计哲学：
npm安装依赖的时候会优先安装在当前项目的目录下，保持各个项目依赖的独立性。

优点：可以减少开发者的心智负担，方便维护各个项目下的不同依赖。
缺点：A项目和B项目都依赖一个包，这时候就会产生依赖重复安装，造成电脑内存资源的浪费。

当然像webpack、creat-react-app这些依赖也可以安装在全局，这样做的目的是为了方便设置环境变量path，让我们可以在任何地方调用对应的命令。
了解了这些以后我们来探究一下npm依赖安装的核心机制。
?

文章图片

通过上图我们可以看到npm安装依赖的整个脉络，接下来我们逐个分析
?
当我们执行npm install命令时，会首先去查找对应的配置文件，来告诉npm要以什么样的规则去下载文件。
config文件有多个，但是遵循一个优先级：
项目级的.npmrc > 用户级的.npmrc > 全局的.npmrc > npm内置的.npmrc文件

我们可以通过 npm config ls -l来查看当前的配置

?
确定了config之后，就会看当前项目下有没有package-lock.json文件。
?
如果有package-lock.json文件，那么会对比pacakge.json和lock文件：

如果依赖版本规范兼容的话，会按照lock文件中的信息进行资源的下载
如果依赖版本规范不兼容的话，不同版本会有不同的处理（详情看上图）

其实大部分情况下两个版本规范都是兼容的，所以大部分都是按照lock文件去安装依赖。
除非你手动更改依赖版本号，可能就会出现不兼容的情况。
总结来说就是：
规范兼容按照 **lock** 下载依赖。
不兼容按照 **package.json** 下载依赖，并且最后更新lock文件。

这里有个问题就是怎么来判断两个依赖的版本是否兼容？
这里需要知道一个知识点，什么是semver？官方文档

如果没有package-lock.json文件，那么就会按照package.json文件去进行依赖树的构建。
?
构建依赖树的时候，遵循扁平化的原则，也就是会优先将依赖放在node_modules的根目录下。后面在安装其他依赖的时候，会判断该依赖是否已经存在，如果存在的话，就会比较两个依赖的版本规范是否兼容，如果兼容则跳过该依赖的安装（忽略该依赖，因为已经存在），如果不兼容的话，会将该版本的依赖单独放在其父级的node_modules中
然后在获取依赖资源的时候会优先考虑缓存，这样可以加快依赖的下载速度。
?
npm依赖缓存策略我们可以通过下面的命令来获取到缓存地址，我们可以在对应的__caches文件夹里查看相关文件。

npm config get cache

那在我们每次install的时候都是怎么进行缓存的读取的呢？
在我们install的时候，npm会先将资源下载到缓存当中，然后才会解压的项目对应的node_modules中。
之后在每次安装资源的时候都会按照package-lock.json文件中的version、integrity、name信息来生成一个key值，这个key值可以命中index-v5中的缓存资源的信息。如果命中缓存了，就会找到对应的tar包，解压到项目中的node_modules中。
?

这里其实可以探究一下这个key值是怎么生成的？
留一个思考：就是如果没有lock文件，是不是就意味着不会从缓存里拿资源了？而是每次都通过网络下载？

npm依赖管理机制首先我们来看一下v2版本的npm依赖管理是怎么做的。
当一个项目中有A和B两个依赖的时候，会在node_modules中依次安装这两个依赖。
并且这两个依赖都有一个共同的依赖项C，那么在v2中就会在A和B文件夹的node_modules中各自安装C。

文章图片

这样就会造成一个问题，那就是依赖地狱。

依赖地狱会造成内存资源的浪费
而且重复安装依赖，会造成安装进度缓慢

为了解决这样的问题，npm从v3开始，就采取了扁平化的结构（其实当前npm很多机制都是借鉴了yarn的设计）。
在扁平化的结构下，npm是怎么进行管理依赖的呢？我们接下来一步步屡清楚。
首先依赖A 有一个依赖项C 版本号为v1，那么在安装依赖的时候就是这样的：

文章图片

然后在安装依赖B的时候，他也依赖v1版本的C，那么他就会从node_modules根目录中寻找该依赖，此时的依赖结构如下：

文章图片

那么如果依赖B，它依赖的C版本是V2，那么结构就会发生变化，B会在自己目录下的node_modules安装对应v2版本的C:

文章图片

根据上面的这种情况，继续往下看如果此时我们需要升级依赖A为v2，该版本的A，不再依赖v1版本的C，而是依赖V2版本的C。那么此时npm会怎么做呢？

删除A
因为v1版本的C已经没有包依赖了，所以也会删除
安装v2版本的A?
因为此时根目录下没有v2的C，v2版本的C会安装在根目录下

文章图片

到这里可能有个问题，为啥都依赖v2版本的C，依赖B还要在自己的目录下单独安装v2的C？
因为B依赖是后安装的，安装B的时候已经在根目录里存在了v1版本的C的包，所以v2版本就安装在了它自身的目录。

从这里就可以看出，在npm里依赖的安装顺序对依赖结构的影响会非常大，可能会影响node_modules的文件大小。
那么我们有办法让它完全扁平化吗？
当然是可以的，npm提供了一个命令，可以帮助我们处理这些重复文件，也可以理解为帮我们扁平化

npm dedupe

执行之后结构就变成了更优雅的形式：

文章图片

这里值得一提的是， yarn在安装依赖的时候会自动执行 dedupe命令，帮我们自动拍平。

这里给大家看一个实际案例，我初始化了一个新的项目，这个项目只安装了一个依赖find-css-import（这个包是我写的，所以比较熟悉），这个包是只有一个依赖strip-comments v2.0。
当我们首次安装这个依赖的时候，项目中的node_modules文件夹就会一次出现这两个文件。

这种现象也是符合上面我们分析的结果的。
然后我们手动的去改一下这个目录结构，把strip-comments文件夹放到find-css-import的node_modules中去，然后在执行一下dedupe来模拟一下扁平化的这个过程。
手动修改后的的目录结构是这样的: