likes
comments
collection
share

2023了,该用一下pnpm了

作者站长头像
站长
· 阅读数 31

前言

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

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

npm,yarn,pnpm的安装区别

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

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

2023了,该用一下pnpm了 2023了,该用一下pnpm了

pnpm的node_modules略有区别。

2023了,该用一下pnpm了

npm/yarn 包结构分析

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

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

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

npmyarn目前给出的方案是将其中一个版本,(假设是)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官网的图。

2023了,该用一下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
评论
请登录