npm 2010出现
yarn 2016 facebook推出替代npm，由于npm最初有性能，安全的缺陷。以下是npm的一些早期缺陷
- 安装包版本无法保证。最初npm没有package-lock.json文件，同一个项目，安装的时候模块版本无法保持一致性。这是由于package.json文件中版本号的缘故。同一个项目，安装的时候无法保持一致性。由于package.json文件中版本号的特点，下面三个版本号在安装的时候代表不同的含义。 “5.0.3”表示安装指定的5.0.3版本，“～5.0.3”表示安装5.0.X中最新的版本，“^5.0.3”表示安装5.X.X中最新的版本。这就麻烦了，常常会出现同一个项目，有的同事是正常的，有的同事会由于安装的版本不一致出现bug。yarn率先推出了yarn.lock。
- 安装报错被覆盖。npm最初安装依赖包时，如果一个包安装出现错误，会继续往下安装
- npm安装速度慢。npm是根据依赖项安装，速度慢，yarn是并行安装速度快。yarn下载过的包都会缓存到本地目录。下次无需重复下载
以上npm在后续都有所改进
npm 在早期采用的是嵌套的 node_modules 结构，直接依赖会平铺在 node_modules 下，子依赖嵌套在直接依赖的 node_modules 中。
比如项目依赖了A 和 C，而 A 和 C 依赖了不同版本的 B@1.0 和 B@2.0，node_modules 结构如下：
node_modules
├── A@1.0.0
│ └── node_modules
│ └── B@1.0.0
└── C@1.0.0
└── node_modules
└── B@2.0.0
如果 D 也依赖 B@1.0，会生成如下的嵌套结构：
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
可以看到同版本的 B 分别被 A 和 D 安装了两次。
在真实场景下，依赖增多，冗余的包也变多，node_modules 最终会堪比黑洞，很快就能把磁盘占满。而且依赖嵌套的深度也会十分可怕，这个就是依赖地狱。
为了将嵌套的依赖尽量打平，避免过深的依赖树和包冗余，npm v3 将子依赖「提升」(hoist)，采用扁平的 node_modules 结构，子依赖会尽量平铺安装在主依赖项所在的目录中。
node_modules
├── A@1.0.0
├── B@1.0.0
└── C@1.0.0
└── node_modules
└── B@2.0.0
不会重复安装加快访问速度，但是造成了新的问题。‘幽灵依赖’等
参考：zhuanlan.zhihu.com/p/526257537…
blog.csdn.net/chhpearl/ar…
