1、前言
相信大家对这三个包管理器都不陌生，但是总有些疑惑，已经有了npm，为什么还要出现yarn、pnpm，有些人不了解，而有些人是模凌两可的知晓一些,接下来我用最直观的包安装方式，这里我通过安装express来详解
2、Npm
对于
npm这里需要区分2.x版本，以及2.x版本以上的，因为这两者在2.x以下版本，npm安装包方式是以嵌套方式安装的包，而2.x版本以上则是平铺方式安装。
2-1、Npm@2.x
这是环境：
node: 4.9.1、npm: 2.15.12我们开始安装
express
也就是说 npm2 的 node_modules 是嵌套的。
这很正常呀？有什么不对么？
这样其实是有问题的，多个包之间难免会有公共的依赖，这样嵌套的话，同样的依赖会复制很多次，会占据比较大的磁盘空间。
这个还不是最大的问题，致命问题是 windows 的文件路径最长是 260 多个字符，这样嵌套是会超过 windows 路径的长度限制的。
当时npm 还没解决，社区就出来新的解决方案了，就是 yarn。
3-1、yarn & npm > 3.x
yarn 是怎么解决依赖重复很多次，嵌套路径过长的问题的呢？
铺平。所有的依赖不再一层层嵌套了，而是全部在同一层，这样也就没有依赖重复多次的问题了，也就没有路径过长的问题了。
但是有些包还是有嵌套问题的，为什么还会有嵌套问题呢？
假设现在我们项目依赖
body-parser@1.19.1，且依赖express，那我们删掉之前测试的
node_modules，重新安装：
npm i express body-parser@1.19.1 -S
发现没有？在
express中又出现了嵌套问题了
因为一个包是可能有多个版本的，提升只能提升一个，所以后面再遇到相同包的不同版本，依然还是用嵌套的方式。
yarn 和 npm@3.x 都采用了铺平的方案，这种方案就没有问题了么？
并不是，扁平化的方案也有相应的问题。
最主要的一个问题是幽灵依赖
而且还有一个问题，就是上面提到的依赖包有多个版本的时候，只会提升一个，那其余版本的包不还是复制了很多次么，依然有浪费磁盘空间的问题。
那社区有没有解决这俩问题的思路呢？
当然有，这不是 pnpm 就出来了嘛。
那 pnpm 是怎么解决这俩问题的呢？
3-2、幽灵依赖
什么是幽灵依赖？
也就是你明明没有声明在 dependencies 里的依赖，但在代码里却可以 require 进来。
假设我们的项目只有一个依赖express
const BodyParser = require('body-parser');
console.log(BodyParser);
我们发现代码可以 正常运行，因为在express中他依赖了body-parser而因为平铺的方式，我们可以直接引入这个包，但是这个是很大的问题！！！
在假设后期项目中不需要依赖express，我们直接卸载了express,但是我们代码中引了body-parser，那么就存在了问题.
幽灵依赖可能会导致以下问题：
项目在不同的环境下表现不一致，因为安装的依赖项版本不同。
可能会安装未经测试的、低质量的或包含漏洞的软件包。
项目构建和部署过程可能会因为依赖项版本不兼容而失败。
4、pnpm
回想下 npm3和yarn 为什么要做node_modules扁平化？不就是因为同样的依赖会复制多次，并且路径过长在 windows 下有问题么？
那如果不复制呢，比如通过link。
首先介绍下 link，也就是软硬连接，这是操作系统提供的机制，硬连接就是同一个文件的不同引用，而软链接是新建一个文件，文件内容指向另一个路径。当然，这俩链接使用起来是差不多的。
如果不复制文件，只在全局仓库保存一份 npm 包的内容，其余的地方都 link 过去呢？
这样不会有复制多次的磁盘空间浪费，而且也不会有路径过长的问题。因为路径过长的限制本质上是不能有太深的目录层级，现在都是各个位置的目录的link，并不是同一个目录，所以也不会有长度限制。
没错，pnpm 就是通过这种思路来实现的。
包是从全局 store 硬连接到虚拟 store 的，这里的虚拟 store 就是 node_modules/.pnpm。
并且确实不是扁平化的了，依赖了 express，那 node_modules 下就只有 express，没有幽灵依赖。
查看.pnpm
所有的依赖都在这里铺平了，都是从全局 store 硬连接过来的，然后包和包之间的依赖关系是通过软链接组织的。
也就是说，所有的依赖都是从全局 store 硬连接到了 node_modules/.pnpm 下，然后之间通过软链接来相互依赖。
官方的原理图
这就是 pnpm 的实现原理。
那么回过头来看一下，pnpm 为什么优秀呢？
首先，最大的优点是节省磁盘空间呀，一个包全局只保存一份，剩下的都是软硬连接，这得节省多少磁盘空间呀。
其次就是快，因为通过链接的方式而不是复制，自然会快。
4-1、如果修改pnpm项目中一个包依赖的源码，有什么影响？为什么？
假设想在有两个项目：《pnpm-obj-1》、《pnpm-obj-2》,其中这两个项目都是用pnpm安装了React最新版本，但如果我修改了其中 "pnpm-obj-1" react的源码，会有什么影响么？
我们实际操作下：
接下来我们只更改
pnpm-test-1中的react源码
然后在查看pnpm-test项目中react源码
总结：
然后我们发现如果在其中一个项目修改依赖包源码，发现其余相同依赖的包也会被修改！！！这是为什么？因为pnpm中的包依赖是通过全局缓存硬连接至项目的。所以当你修改其中一个包源码，会影响其他项目的包，所以使用pnpm包慎重修改包的源码！！！
通过这个案例，又延伸一个问题，这样修改包源码，会影响新的项目新安装相同的依赖么？
4-2、修改旧项目包源码，会影响新项目包的源码么？
我们直接说结果，是不会影响的。那有人在问，上诉我们修改旧项目的源文件，因为硬连接的原因，也就是相当于修改了pnpm全局store的中的源文件包，而，pnpm新安装包是检测全局store有没有这个包，如果有那么直接硬连接过来，而达到快速的安装包，那为什么新安装的包不会受到影响？
总结
pnpm 最近经常会听到，可以说是爆火。本文我们梳理了下它爆火的原因：
npm2 是通过嵌套的方式管理 node_modules 的，会有同样的依赖复制多次的问题。
npm3+ 和 yarn 是通过铺平的扁平化的方式来管理 node_modules，解决了嵌套方式的部分问题，但是引入了幽灵依赖的问题，并且同名的包只会提升一个版本的，其余的版本依然会复制多次。
pnpm 则是用了另一种方式，不再是复制了，而是都从全局 store 硬连接到 node_modules/.pnpm，然后之间通过软链接来组织依赖关系。
这样不但节省磁盘空间，也没有幽灵依赖问题，安装速度还快，从机制上来说完胜 npm 和 yarn。
pnpm 就是凭借这个对 npm 和 yarn 降维打击的。
