1、前言

相信大家对这三个包管理器都不陌生，但是总有些疑惑，已经有了npm，为什么还要出现yarn、pnpm，有些人不了解，而有些人是模凌两可的知晓一些,接下来我用最直观的包安装方式，这里我通过安装express来详解

2、Npm

对于npm这里需要区分2.x版本，以及2.x版本以上的，因为这两者在2.x以下版本，npm安装包方式是以嵌套方式安装的包，而2.x版本以上则是平铺方式安装。

2-1、Npm@2.x

image.png

image.png

也就是说 npm2 的 node_modules 是嵌套的。

这很正常呀？有什么不对么？

这样其实是有问题的，多个包之间难免会有公共的依赖，这样嵌套的话，同样的依赖会复制很多次，会占据比较大的磁盘空间。

这个还不是最大的问题，致命问题是 windows 的文件路径最长是 260 多个字符，这样嵌套是会超过 windows 路径的长度限制的。

当时npm 还没解决，社区就出来新的解决方案了，就是 yarn。

3-1、yarn & npm > 3.x

yarn 是怎么解决依赖重复很多次，嵌套路径过长的问题的呢？

铺平。所有的依赖不再一层层嵌套了，而是全部在同一层，这样也就没有依赖重复多次的问题了，也就没有路径过长的问题了。

image.png

npm i express body-parser@1.19.1 -S

image.png

因为一个包是可能有多个版本的，提升只能提升一个，所以后面再遇到相同包的不同版本，依然还是用嵌套的方式。

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 就是通过这种思路来实现的。

image.png

包是从全局 store 硬连接到虚拟 store 的，这里的虚拟 store 就是 node_modules/.pnpm。

并且确实不是扁平化的了，依赖了 express，那 node_modules 下就只有 express，没有幽灵依赖。

查看.pnpm

image.png

也就是说，所有的依赖都是从全局 store 硬连接到了 node_modules/.pnpm 下，然后之间通过软链接来相互依赖。

官方的原理图

image.png

这就是 pnpm 的实现原理。

那么回过头来看一下，pnpm 为什么优秀呢？

首先，最大的优点是节省磁盘空间呀，一个包全局只保存一份，剩下的都是软硬连接，这得节省多少磁盘空间呀。

其次就是快，因为通过链接的方式而不是复制，自然会快。

4-1、如果修改pnpm项目中一个包依赖的源码，有什么影响？为什么？

假设想在有两个项目：《pnpm-obj-1》、《pnpm-obj-2》,其中这两个项目都是用pnpm安装了React最新版本，但如果我修改了其中 "pnpm-obj-1" react的源码，会有什么影响么？

我们实际操作下：

image.png

修改源码

然后在查看pnpm-test项目中react源码

pnpm-test

然后我们发现如果在其中一个项目修改依赖包源码，发现其余相同依赖的包也会被修改！！！这是为什么？因为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 降维打击的。