深入浅出分析npm和pnpm的区别 : 深入浅出 npm & yarn & pnpm 包管理机制 - 知乎
npm的缺点
幽灵依赖
幽灵依赖是指在 package.json 中未定义的依赖,但项目中依然可以正确地被引用到。 比如A依赖了B, 所以安装A后,B会和A同级出现,所以项目中可以正常引用B,但package.json中却没有声明对B的依赖 幽灵依赖是由依赖的声明丢失造成的,如果某天某个版本的 A 依赖不再依赖 B 或者 B 的版本发生了变化,那么就会造成依赖缺失或兼容性问题。
依赖分身
如果是以下的依赖场景
-
A 和 D 依赖 B@1.0
-
C 和 E 依赖 B@2.0
那么B@1.0和AD同级,而C和E下会各安装一次B@2.0, 即B@2.0被重复安装
pnpm的优点
pnpm - performant npm,在 2017 年正式发布,定义为快速的,节省磁盘空间的包管理工具,开创了一套新的依赖管理机制,成为了包管理的后起之秀 与依赖提升和扁平化的 node_modules 不同,pnpm 引入了另一套依赖管理策略:内容寻址存储。 该策略会将包安装在pnpm系统的全局 store 中,依赖的每个版本只会在系统中安装一次。 在引用项目 node_modules 的依赖时,会通过硬链接与符号链接在全局 store 中找到这个文件。为了实现此过程,node_modules 下会多出 .pnpm 目录,而且是非扁平化结构。
-
硬链接 Hard link:硬链接可以理解为源文件的副本,项目里安装的其实是副本,它使得用户可以通过路径引用查找到全局 store 中的源文件,而且这个副本根本不占任何空间。同时,pnpm 会在全局 store 里存储硬链接,不同的项目可以从全局 store 寻找到同一个依赖,大大地节省了磁盘空间。
-
符号链接 Symbolic link:也叫软连接,可以理解为快捷方式,pnpm 可以通过它找到对应磁盘目录下的依赖地址。
这套全新的机制设计地十分巧妙,不仅兼容 node 的依赖解析,同时也解决了:
-
幽灵依赖问题:只有直接依赖会平铺在 node_modules 下,子依赖不会被提升,不会产生幽灵依赖。
-
依赖分身问题:相同的依赖只会在全局 store 中安装一次。项目中的都是源文件的副本,几乎不占用任何空间,没有了依赖分身。
同时,由于链接的优势,pnpm 的安装速度在大多数场景都比 npm 和 yarn 快 2 倍,节省的磁盘空间也更多。
34



被折叠的 条评论
为什么被折叠?



