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
转载自:https://juejin.cn/post/7237856777588670521