前端工程化基建学习（1）学习了解npm的核心原理和内部机制

前言

        首先写这篇文章是为了个人学习以及回顾的时候可以自己看的，也会参考到其他大牛的文章，不作盈利目的，如涉及侵权麻烦联系我删除，如有雷同请谅解，大家一同学习。

一、从内部机制和核心原理了解npm

1.1 、npm 的安装机制和背后思想

1、npm install 执行之后，首先，检查并获取 npm 配置

2、检查项目中是否有 package-lock.json 文件

1.  若有： 检查 package-lock.json 和 package.json 中声明的依赖是否一致：一致就直接使用package-lock.json 中的信息，从缓存或网络资源中加载依赖；不一致，则依据npm的版本进行处理

2. 若无：则根据 package.json 递归构建依赖树，按照构建好的依赖树下载完整的依赖资源，在下载时就会检查是否存在相关资源缓存：存在缓存，就会将缓存内容解压到node_modules 中；不存在缓存，就从npm远程仓库下载包，并会检验包的完整性，随后添加到缓存，解压到node_modules 中生成package-lock.json。

3、最后生成 package-lock.json

1.2 、package-lock.json的作用

它的作用锁定安装时的包的版本号及包的依赖的版本号, 以保证其他所有人人在使用 ​​npm install​​ 时下载的依赖包都是一致的。

dependencies 是一个对象，对象和 node_modules 中的包结构一一对应，对象的 key 为包名称，值为包的一些描述信息：

1. version： 包版本这个包当前安装在 node_modules 中的版本
2. resolved： 包具体的安装来源，通常是npm，也有是私有源
3. integrity： 包 hash 值，来判断安装的依赖包是否被改动过、是否已失效源
4. requires： 对应子依赖的依赖，与子依赖的 package.json 中 dependencies的依赖项相同
5. dependencies： 存储安装在子依赖 node_modules 中的依赖包。

这里注意，并不是所有的子依赖都有 dependencies 属性，只有子依赖的依赖和当前已安装在根目录的 node_modules 中的依赖冲突之后，才会有这个属性。

1.3 node_modules 中模块目录结构

npm3.x之前是嵌套结构，那时候如果我们的项目中依赖了公共库 A 和公共库 B，同时公共库 A 也依赖了公共库 B，那公共库 B 会被多次安装

node_modules 的结构和 package.json 结构一一对应，层级结构明显，并且保证了每次安装目录结构都是相同的。但是一个项目中引用的模块非常多，嵌套层级很深这时候就出现:在不同层级的依赖中，可能引用了同一个模块，这样这个模块就存在多个地方。显然不符合编码简洁的思路。

为了解决以上问题，npm3版本进行了改造。把嵌套结构改为扁平结构: 安装模块时，不管其是直接依赖还是子依赖的依赖，优先将其安装在 node_modules 根目录。

参考文章作者：codercao
参考链接：https://juejin.cn/post/7156041372678488072