很久没有写文章了，写这篇文章的起因是上周碰到的一道面试题。请你实现一个npm install
那么就写一篇短文来简单探讨一下它的构建流程
常识我们都知道，如在执行npm install之后，它去package.json下找dependencies。借助这个”map“去将此项目的所有依赖写入node_modules文件下。
文件的下载与写入当然没有什么难度，这里的核心在于依赖树的创建
先看一个简单的依赖关系
但是如果2也依赖4呢？
首先在以前的npm版本是这样做的
这样做虽然很清晰，但是如果这棵依赖树比较庞大，并且存在很多上图所述的情况。无论是对于内存还是请求都是比较浪费的
所以在npm3之后，改变了一下策略。把这棵树尽量的拍平了一下。什么意思呢？
它会在遍历依赖包时，首先先将这个节点放到树的第一层上去。即比如上图的4个依赖，都会挂到第一层不往下构建子树，这时候又来一个依赖4节点。那么首先就会判断它是否已经处在第一层，已经有了那就不用处理。
如果按照先序遍历构建
如果给他们在加上版本呢？
比如 1依赖 4.1 2依赖 4.2，这时候又怎样构建呢？
这时候就会采用npm 2+npm 3这种混合的方式进行构建。即在构建4.2时第一层已有4.1。那么这个4.2还是会挂到它本来的父亲身上
本来依赖树
构建之后的依赖树
这样看起来好像是解决了npm2之前的问题，但是构建依赖的时候。开始构建的顺序取决于dependencies中的书写顺序。
会有什么问题呢？再举个栗子
假如本来的依赖关系是这样的
构建完之后
这时候看着还没有什么问题，如果换一下dependencies中的顺序呢？比如这样
构建完成之后
可见，根本上构建中重复问题还是没有解决掉
怎么办呢？npm在5.x又整出了lock文件（package-lock.json）用于锁定依赖结构。这就不在我这篇之内了
