node_modules
└─ 依赖A
├─ index.js
├─ package.json
└─ node_modules
└─ 依赖C
├─ index.js
├─ package.json
└─ node_modules
└─ 依赖B
├─ index.js
├─ package.json
└─ node_modules
node_modules下所有的依赖都会平铺到同一层级。由于require寻找包的机制，如果A和C都依赖了B，那么A和C在自己的node_modules中未找到依赖C的时候会向上寻找，并最终在与他们同级的node_modules中找到依赖包C。 这样就不会出现重复下载的情况。而且依赖层级嵌套也不会太深。因为没有重复的下载，所有的A和C都会寻找并依赖于同一个B包。自然也就解决了实例无法共享数据的问题
由于这个扁平化结构的特点，想必大家都遇到了这样的体验，自己明明就只安装了一个依赖包，打开node_modules文件夹一看，里面却有一大堆。
这种扁平化结构虽然是解决了之前的嵌套问题，但同时也带来了另外一些问题：
依赖结构的不确定性
扁平化算法的复杂度增加
项目中仍然可以非法访问没有声明过的依赖包(幽灵依赖)
依赖结构的不确定性
这个怎么理解，为什么会产生这种问题呢？我们来仔细想想，加入有如下一种依赖结构：
A包与B包同时依赖了C包的不同版本，由于同一目录下不能出现两个同名文件，所以这种情况下同一层级只能存在一个版本的包，另外一个版本还是要被嵌套依赖。
那么问题又来了，既然是要一个扁平化一个嵌套，那么这时候是如何确定哪一个扁平化哪一个嵌套的呢？
这两种结构都有可能，准确点说哪个版本的包被提升，取决于包的安装顺序！
这就是为什么会产生依赖结构的不确定问题，也是 lock 文件诞生的原因，无论是package-lock.json(npm 5.x 才出现)还是yarn.lock，都是为了保证 install 之后都产生确定的node_modules结构。
尽管如此，npm/yarn 本身还是存在扁平化算法复杂和package 非法访问的问题，影响性能和安全。
前面说了那么多的npm与yarn的缺点，现在再来看看pnpm是如何解决这些尴尬问题的。
什么是pnpm
快速的，节省磁盘空间的包管理工具
就这么简单，说白了它跟npm与yarn没有区别，都是包管理工具。但它的独特之处在于：
包安装速度极快
磁盘空间利用非常高效
安装包速度快
从上图可以看出，pnpm的包安装速度明显快于其它包管理工具。那么它为什么会比其它包管理工具快呢？
我们来可以来看一下各自的安装流程
npm/yarn
上图是pnpm的安装流程，可以看到针对每个包的三个流程都是平行的，所以速度会快很多。当然pnpm会多一个阶段，就是通过链接组织起真正的依赖树目录结构。
磁盘空间利用非常高效
pnpm 内部使用基于内容寻址的文件系统来存储磁盘上所有的文件，这个文件系统出色的地方在于:
不会重复安装同一个包。用 npm/yarn 的时候，如果 100 个项目都依赖 lodash，那么 lodash 很可能就被安装了 100 次，磁盘中就有 100 个地方写入了这部分代码。但在使用 pnpm 只会安装一次，磁盘中只有一个地方写入，后面再次使用都会直接使用 hardlink。
即使一个包的不同版本，pnpm 也会极大程度地复用之前版本的代码。举个例子，比如 lodash 有 100 个文件，更新版本之后多了一个文件，那么磁盘当中并不会重新写入 101 个文件，而是保留原来的 100 个文件的 hardlink，仅仅写入那一个新增的文件。
支持monorepo
pnpm 与 npm/yarn 另外一个很大的不同就是支持了 monorepo，pnpm内置了对monorepo的支持，只需在工作空间的根目录创建pnpm-workspace.yaml和.npmrc配置文件，同时还支持多种配置，相比较lerna和yarn workspace，pnpm解决monorepo的同时，也解决了传统方案引入的问题。
monorepo 的宗旨就是用一个 git 仓库来管理多个子项目，所有的子项目都存放在根目录的packages目录下，那么一个子项目就代表一个package。
pnpm使用的是npm version 2.x类似的嵌套结构，同时使用.pnpm 以平铺的形式储存着所有的包。然后使用Store + Links和文件资源进行关联。简单说pnpm把会包下载到一个公共目录，如果某个依赖在 sotre 目录中存在了话，那么就会直接从 store 目录里面去 hard-link，避免了二次安装带来的时间消耗，如果依赖在 store 目录里面不存在的话，就会去下载一次。通过Store + hard link的方式，使得项目中不存在NPM依赖地狱问题，从而完美解决了npm3+和yarn中的包重复问题。
我们分别用npm与pnpm来安装vite对比看一下
pnpm安装的vite 所有的依赖都软链至了 node_modules/.pnpm/ 中的对应目录。 把 vite 的依赖放置在同一级别避免了循环的软链。
软链接 和 硬链接 机制
pnpm 是通过 hardlink 在全局里面搞个 store 目录来存储 node_modules 依赖里面的 hard link 地址，然后在引用依赖的时候则是通过 symlink 去找到对应虚拟磁盘目录下(.pnpm 目录)的依赖地址。
这两者结合在一起工作之后，假如有一个项目依赖了 A@1.0.0 和 B@1.0.0 ，那么最后的 node_modules 结构呈现出来的依赖结构可能会是这样的:
node_modules
└── A // symlink to .pnpm/A@1.0.0/node_modules/A
└── B // symlink to .pnpm/B@1.0.0/node_modules/B
└── .pnpm
├── A@1.0.0
│ └── node_modules
│ └── A -> <store>/A
│ ├── index.js
│ └── package.json
└── B@1.0.0
└── node_modules
└── B -> <store>/B
├── index.js
└── package.json
node_modules 中的 A 和 B 两个目录会软连接到 .pnpm 这个目录下的真实依赖中，而这些真实依赖则是通过 hard link 存储到全局的 store 目录中。
store
pnpm下载的依赖全部都存储到store中去了，store是pnpm在硬盘上的公共存储空间。
pnpm的store在Mac/linux中默认会设置到{home dir}>/.pnpm-store/v3；windows下会设置到当前盘符的根目录下。使用名为 .pnpm-store的文件夹名称。
项目中所有.pnpm/依赖名@版本号/node_modules/下的软连接都会连接到pnpm的store中去。
原文首发地址点这里，欢迎大家关注公众号 「前端南玖」，如果你想进前端交流群一起学习，请点这里
我是南玖，我们下期见！！！
-------------------------------------------
如果这篇文章有帮助到你，❤️关注+点赞❤️鼓励一下作者，文章公众号首发，关注 前端南玖 第一时间获取最新的文章～
扫描下方二维码关注公众号，回复进群，拉你进前端学习交流群
