从这篇文章中能取得什么？
- 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来模仿一下扁平化的这个过程。
手动批改后的的目录构造是这样的:
而后咱们去执行一下dedupe
能够看到它胜利的将文件构造给拍平了~
总结
这篇文章其实是一篇笔记，对本人这两天看到的常识进行一个演绎总结。
其实说起来想包管理工具尽管日常咱们常常应用，然而有很多细节都是疏忽的，也是心愿通过这篇文章来捡起来一些货色。
参考
- LucasHC（侯策）老师 - 前端根底建设与架构30讲
- 山月老师 - 什么是semver
文章始发与公众号：前端程序喵，欢送大家关注