2023了，该用一下pnpm了

前言

大家好，我是 simple ，我的理想是利用科技手段来解决生活中遇到的各种问题。

performant npm ，意味高性能的 npm。pnpm由 npm/yarn 衍生而来，解决了 npm/yarn 内部潜在的bug，极大的优化了性能，扩展了使用场景。被誉为"最先进的包管理工具"。

npm,yarn,pnpm的安装区别

首先我创建了三个文件夹分别是npm，yarn和pnpm用于比较三者之间的区别。首先初始化项目，然后安装了express来观察三个文件夹的区别。

npm和yarn的node_modules都是点开之后一眼看不到尽头。

pnpm的node_modules略有区别。

npm/yarn 包结构分析

出现这种情况，是因为yarn和npm安装依赖包，会在node_modules下都平铺出来。现在安装了express，但express中也会有很多不同的依赖。在这些依赖里面有可能又引用了新的依赖，导致node_modules一点开就一望无际了。

初心是好的，因为平铺就可以复用很多依赖。如果说我package A和package B都用了lodash@3.0.0这个包，那么使用平铺，我只需要下载一次lodash即可，节约了装包时间和存储空间。

但是真实开发情况往往是现在下载了五个依赖，其中A,B依赖引用了lodash@3.0.0，而C,D,E引用了lodash@4.0.0。咋整？

npm和yarn目前给出的方案是将其中一个版本，(假设是)lodash@3.0.0的版本放在根目录的node_modules下面，而将需要lodash@4.0.0版本安装到C,D,E的node_modules下。如下所示，A, B可以直接使用lodash@3.0.0，而4,5,6想要使用就只能独自安装lodash@4.0.0。

├─── lodash@3.0.0

├─── package-A

├─── package-B

├─── package-C

│     └── lodash@4.0.0

├─── package-D

│     └── lodash@4.0.0

├─── package-E

│     └── lodash@4.0.0

pnpm包结构分析

按照上文的例子，如果pnpm也安装五个包，A,B依赖引用了lodash@3.0.0，而C,D,E引用了lodash@4.0.0。

├─ .pnpm

│     └── lodash@3.0.0

│     └── lodash@4.0.0

│     └── package-A@1.0.0

│     └── package-B@1.0.0

│     └── package-C@1.0.0

│     └── package-D@1.0.0

│     └── package-E@1.0.0

├──── package-A 符号链接

├──── package-B 符号链接

├──── package-C 符号链接

├──── package-D 符号链接

├──── package-E 符号链接

在pnpm文件夹的node_modules下除了.pnpm文件夹外，就剩下一个package A,B,C,D,E，并且这五个包都是符号链接，它们真正的地址都是在.pnpm下。

也就是说，pnpm通过.pnpm/<name>@<version>/node_modules/<name>找到不同的包，这不仅解决了包重复下载的问题，还顺手解决了幽灵依赖的问题。

幽灵依赖：即开发者并未在package.json中下载相关包，但是在开发过程中却可以直接引用的问题。就是因为npm将依赖直接在node_modules下直接展开，导致开发者可以直接引用。问题就是当开发者升级一些包的时候，那些幽灵依赖可能并不存在于新的版本中，导致项目崩溃。

.pnpm store

pnpm牛皮的地方不只是借用了符号链接解决了包引用的问题，更是借助了硬链接解决了整个直接所有的项目依赖都给整合了，一个包全局只保存一份，并且是通过链接，速度比复制还要快的多。

借一张pnpm官网的图。

从图可以看出，.pnpm store就是依赖的实际存储位置，Mac/linux在{home dir}>/.pnpm-store/v3，windows在当前盘/.pnpm-store/v3。这样就会有个好处，你在多个项目使用的是同一个依赖时，一个包全局只保存一份，这也太省空间了吧。（只要你下载过一次，如果你没有清理.pnpm store，第二次就算你不联网照样能帮你install。）

pnpm store清理

但是，随着使用时间越长，pnpm store也会越来越大。并且随着项目版本的迭代，可能很多包都不再需要了pnpm store依旧会保留着它。此时我们需要定时清理一下。

未引用的包是系统上的任何项目中都未使用的包。 在大多数安装操作之后，包有可能会变为未引用状态，例如当依赖项变得多余时。

最好的做法是 pnpm store prune 来清理存储，但不要太频繁。 有时，未引用的包会再次被需要。 这可能在切换分支和安装旧的依赖项时发生，在这种情况下，pnpm 需要重新下载所有删除的包，会暂时减慢安装过程。

请注意，当 存储服务器正在运行时，这个命令是禁止使用的。

pnpm store prune