php网站开发实验总结,广州软件开发,中国展览公司前十名,网络认证工程师前言
pnpm对比npm/yarn的优点#xff1a;
更快速的依赖下载更高效的利用磁盘空间更优秀的依赖管理 我们按照包管理工具的发展历史#xff0c;从 npm2 开始讲起#xff1a;
npm2
使用早期的npm1/2安装依赖#xff0c;node_modules文件会以递归的形式呈现#xff0c;严格…前言
pnpm对比npm/yarn的优点
更快速的依赖下载更高效的利用磁盘空间更优秀的依赖管理 我们按照包管理工具的发展历史从 npm2 开始讲起
npm2
使用早期的npm1/2安装依赖node_modules文件会以递归的形式呈现严格按照package.json结构以及次级依赖的package.json将依赖安装到各自的node_modules中直至次级依赖不再依赖其他模块
举例
foo - barfoo依赖于bar
node_modules
└─ foo├─ index.js├─ package.json└─ node_modules└─ bar├─ index.js└─ package.jsonfoo1 - barfoo2 - barbar会被安装两次
node_modules
├─ foo1
│ ├─ index.js
│ ├─ package.json
│ └─ node_modules
│ └─ bar
│ ├─ index.js
│ └─ package.json
└─ foo2├─ index.js├─ package.json└─ node_modules└─ bar├─ index.js└─ package.json一些其他问题 ● 依赖层级太深会导致文件路径过长windows 的文件路径最长是 260 多个字符这样嵌套是会超过 windows 路径的长度限制的。 ● 这样的嵌套重复的包被安装导致node_modules文件体积巨大占用过多的磁盘空间
当时 npm 还没解决社区就出来新的解决方案了就是 yarn
npm3/yarn
yarn 是怎么解决依赖重复很多次嵌套路径过长的问题的呢 铺平。所有的依赖不再一层层嵌套了而是全部在同一层采用“扁平化”的方式去管理依赖这样也就没有依赖重复多次的问题了也就没有路径过长的问题了。
举例
foo1 - barfoo2 - bar
node_modules
├─ bar
│ ├─ index.js
│ └─ package.json
├─ foo1
│ ├─ index.js
│ └─ package.json
└─ foo2├─ index.js└─ package.jsonfoo1 - bar1.0.0foo2 - bar2.0.0
node_modules
├─ bar1.0.0
│ ├─ index.js
│ └─ package.json
├─ foo1
│ ├─ index.js
│ └─ package.json
└─ foo2├─ index.js└─ package.json└─ node_modules└─ bar2.0.0├─ index.js└─ package.json为什么还有嵌套呢 因为一个包是可能有多个版本的提升只能提升一个所以后面再遇到相同包的不同版本依然还是用嵌套的方式。
使用扁平化的方案解决了npm2中出现的问题但是也带来一些问题
幽灵依赖 就是明明没有在dependencies中声明的依赖但是却可以require进来。很容易理解就是依赖都铺平了那依赖的依赖也是可以找到的。
出现幽灵依赖是有隐患的比如因为没有显式依赖万一有一天别的包不依赖这个包了那你的代码也就不能跑了因为你依赖这个包但是现在不会被安装了。
浪费磁盘空间的问题 上面提到的依赖包有多个版本的时候只会提升一个那其余版本的包不还是复制了很多次么依然有浪费磁盘空间的问题。
那社区有没有解决这俩问题的思路呢 当然有这不是 pnpm 就出来了嘛。 那 pnpm 是怎么解决这俩问题的呢
pnpm
回想下 npm3 和 yarn 为什么要做 node_modules 扁平化不就是因为同样的依赖会复制多次并且路径过长在 windows 下有问题么 那如果不复制呢比如通过 link。 首先介绍下 link也就是软硬连接这是操作系统提供的机制。
硬连接就是同一个文件的不同引用而软链接是新建一个文件文件内容指向另一个路径。当然这俩链接使用起来是差不多的。
如果不复制文件只在全局仓库保存一份 npm 包的内容其余的地方都 link 过去呢
这样不会有复制多次的磁盘空间浪费而且也不会有路径过长的问题。因为路径过长的限制本质上是不能有太深的目录层级现在都是各个位置的目录的 link并不是同一个目录所以也不会有长度限制。
没错pnpm 就是通过这种思路来实现的。
再把 node_modules 删掉然后用 pnpm 重新装一遍执行 pnpm install。 你会发现它打印了这样一句话 包是从全局 store 硬连接到虚拟 store 的这里的虚拟 store 就是 node_modules/.pnpm。 只要是在同一台机器下下次安装依赖的时候pnpm会先检查store目录如果有你需要安装的依赖则会通过一个硬链接到你的项目中去而不是重新安装依赖。这也就表明为什么pnpm性能这么突出了最大程度的节省了时间消耗和磁盘空间。
我们打开 node_modules 看一下
确实不是扁平化的了依赖了 express那 node_modules 下就只有 express没有幽灵依赖。
展开 .pnpm 看一下
所有的依赖都在这里铺平了都是从全局 store 硬连接过来的然后包和包之间的依赖关系是通过软链接组织的。
比如 .pnpm 下的 expresss这些都是软链接
也就是说所有的依赖都是从全局 store 硬连接到了 node_modules/.pnpm 下然后之间通过软链接来相互依赖。
举例说明
项目依赖foo1.0.0
node_modules
├─ .pnpm
│ └─ foo1.0.0
│ └─ node_modules
│ └─ foo - store/foo
│ ├─ index.js
│ └─ package.json
│
└─ foo项目依赖了foo1.0.0、bar1.0.0bar也依赖了foo1.0.0
node_modules
├─foo - ./.pnpm/foo1.0.0/node_modules/foo
├─bar - ./.pnpm/bar1.0.0/node_modules/bar
└─.pnpm├─ bar1.0.0│ └─ node_modules│ ├─ foo - ../../foo1.0.0/node_modules/foo│ └─ bar - store/bar└─ foo1.0.0└─ node_modules└─ foo - store/foo为什么需要同软链接的方式去引用实际的依赖呢其实这样设计的目的是解决“幽灵依赖”问题只有声明过的依赖才会以软链接的形式出现在node_modules目录中在实际项目中引用的是软链接软链接指向的是 .pnpm 的真实依赖所以在日常开发中不会引用到未在 package.json 声明的包。
官方给了一张原理图配合着看一下就明白了 这就是 pnpm 的实现原理。 那么回过头来看一下pnpm 为什么优秀呢 首先最大的优点是节省磁盘空间呀一个包全局只保存一份剩下的都是软硬连接这得节省多少磁盘空间呀。 其次就是快因为通过链接的方式而不是复制自然会快。 这也是它所标榜的优点 相比 npm2 的优点就是不会进行同样依赖的多次复制。 相比 yarn 和 npm3 呢那就是没有幽灵依赖也不会有没有被提升的依赖依然复制多份的问题。 这就已经足够优秀了对 yarn 和 npm 可以说是降维打击。 Workspace 现代前端工程中居多都是使用 Lerna 管理 monorepo 类型的项目每个人都清楚它的作用而 pnpm 也是对此进行了友好的支持。与 Lerna 不同的是 pnpm 使用特殊的包选择器语法限制命令不像 Lerna 那样需要很长难记的命令去标识。
一个 monorepo 工程目录中必须要拥有管理工作区的配置文件pnpm.workspace.yaml相比其它包管理工具的工作区文件其实都大同小异。
packages:# 所有在 packages/ 和 components/ 子目录下的 package- packages/**- components/**# 不包括在 test 文件夹下的 package- !**/test/**一些常用于管理 monorepo 的命令: ● 精确选择一个 repo scope/package或选择一组 repo scope/*再或者相对路径选择。
pnpm dev --filter byted-ehi/basic-list
pnpm dev --filter apps/*
pnpm dev --filter ./apps/admin-order-manage● 选择一个 repo 以及所属 repo 的依赖项例如会运行 basic-list 下的所有依赖的 dev。这个命令的意思是在 byted-ehi/basic-list 包的所有子目录以及这些子目录中的所有文件中执行开发脚本。
pnpm dev --filter byted-ehi/basic-list...● 只选择某个 repo 的依赖项与上面的区别是不包含 repo。例如会运行 repo 下所有依赖的 dev不包含repo 本身。这个命令的意思是在 byted-ehi/basic-list 包的所有子目录中执行开发脚本。
pnpm dev --filter byted-ehi/basic-list^...● 选择指定目录下的所有 repo。
pnpm dev --filter ./apps总结 pnpm 最近经常会听到可以说是爆火。本文我们梳理了下它爆火的原因 npm2 是通过嵌套的方式管理 node_modules 的会有同样的依赖复制多次的问题。 npm3 和 yarn 是通过铺平的扁平化的方式来管理 node_modules解决了嵌套方式的部分问题但是引入了幽灵依赖的问题并且同名的包只会提升一个版本的其余的版本依然会复制多次。 pnpm 则是用了另一种方式不再是复制了而是都从全局 store 硬连接到 node_modules/.pnpm然后之间通过软链接来组织依赖关系。 这样不但节省磁盘空间也没有幽灵依赖问题安装速度还快从机制上来说完胜 npm 和 yarn。 pnpm 就是凭借这个对 npm 和 yarn 降维打击的。
