目前组里的业务组件库因为一些历史背景原因,源码和展示站点分为两个独立的项目工程维护,而市面上对于组件、组件库、工具库的源码和站点在一个仓库维护或者采用 MonoRepo 的方式开发和维护,因此在不改变项目架构的前提下(暂时不要纠结为什么不放在一起维护),我们对于效率协同和工程化方面进行了一系列的演进,下面首先介绍下我们当前面临的问题:
因为源码和站点维护在两个工程下,在本地开发的时候如何关联两个项目是首先面临的问题,最初我们采用了 npm link 的方式,但是因为组件库和站点均是基于 react hook 开发,因此每次进行组件迭代开发都需要经历下面几步:
不难发现,这样的方案有以下痛点(每个新参与开发的同学都会吐槽 diss):
这一版我们完全抛弃了 npm link,采取了比较 hack 的方式:
不难发现,这样的方案有以下痛点:
既然站点和源码都具有编译构建能力,为什么不减少一次编译构建呢?为此我们进行了第三次优化升级:
源码本地开发的优化使得站点编译压力的增加:
其实到现在这一步问题已经一定程度往 webpack 衍生方案的通病上靠了,因此,我们把目标聚焦在了新的构建工具上。
下面我列举了一常见的构建工具以及以及一些选型思考。
首先是 Webpack 以及 Webpack 衍生方案:
基于 Webpack 的方案和目前使用的脚手架差异不大,收益不明显,并且从根本上也解决不了 Webpack 带来的生产力问题。
接下来是目前比较火的基于 ESM 的现代方案:
关于比较尤大的文章更有说服力:对比。
此外,就我个人而言,我觉得尤大在华人社区以及国内的影响力更大一些,因此尤大开源的工具在国内社区活跃度会更高一些,关注度也会更高,对于后续的可持续发展也比较有利,因此在选型上我们选择了 Vite。
喜大普奔,收效显著!!!
首次冷启动:esbuild 预编译,生成缓存
再次冷启动:利用缓存
首先冷启动为什么快,因为 Vite 基于原生 ESM,也就是说 Vite 将原来 Webpack 前置构建 bundle 的工作交给了性能强悍的现在浏览器来做,所以冷启动时间大幅缩减(毕竟冷启动最耗时的就是分析代码构建 bundle)。
而在 Vite 中,正如官方文档介绍的那样,Vite 将我们的代码氛围了依赖和源码两部分:
以 Webpack 为代表的“bundle based dev server”,在冷启动前需要依赖诸如 babel 之类的工具对代码进行分析并编译生成可运行的 bundle,这一构建时的过程造成了冷启动时间过长。
而对于“ESM base dev server”来说,dev server 依赖的是我们 ESM,而我们的代码本身就是以 ESM 编写的,因此进去要告知 dev server 目标模块路径加载即可,编译解析交给浏览器的运行时去处理,从而大大加速了我们的冷启动。
在 Vite 中,HMR 是在原生 ESM 上执行的。和冷启动一样的道理,当我们修改了一个文件后,不需要在重新编译了,热更新也就大大减少耗时了。
Vite 充份利用了 http 缓存,这也是我们在本地开发时候看到的一个和 webpack 比较大的不同,network 中充满了大量模块请求。
那么如何平稳的从 Webpack 迁移到 Vite ? 其实,当你按照 Vite 文档落地的时候已经兼容 80%的 Webpack 场景。只需要考虑一些额外 case:
Vite 利用了 esBuild 去预构建 ESM,因此对包的要求相对严格,对于 esBuild 预编译失败的场景需要 case by case 处理。
例如:
这里以 react-virtualized 为例,react-virtualized 的 WindowScroll.js 下引入了 flow 的类型文件导致预编译失败。
可以写 esBuild 插件、写 resolutions、拉包本地改。
以 react-infinite-scroller 为例,他在 package.json 中 ESM 读取目录指向了发包后被忽略的 src 源码目录,导致 dep-scan 插件查找模块失败。
Vite 构建过程由 esBuild 接管,而 esBuild 支持的 target 的最低版本为 es6,因此想要构建兼容性更强的 bundle 需要对 Vite 的产出二次编译或者使用官方给出的基于 SystemJS 的方案。
下面这张图是截取的 Vite 官网的兼容性一节:
使用官方插件:
向我们组件库的展示站点或者内部系统的工程项目说用了就用了,但是实际投入到对外的项目时我们也不得不考虑一些问题:
单说从 Webpack 切换到 Vite 成本很低,甚至比 Webpack 的大版本升级还要简单。但是从 Webpack 到 Vite 不仅仅是构建工具的转换而是整个生态的迁移,那么对于历史项目已存在的 babel 插件、Webpack 插件等都需要等量替换,这是一个成本。此外,就像上一节说的那些,对于一些不规范的三方包我们也需要做额外的适配,这也是一个成本。
从目前看,Vite 带来的工程效率收益比较高,但是就我个人而言尝试的仅是简单的展示站点,并不能严格和实际的业务工程划等号,并且企业级项目工程量和复杂度都比较大,Vite 是否能符合预期的带来收益我个人还不敢保证。
最后,因为涉及到了 ESM,就算官方给出了 SystemJs 版本的兼容插件,但是实际投入对外项目的兼容性风险也还是未知的。
Dreamweaver中怎么使用流体网格布局呢?下面我们就来看看详细的教程,请看下文详...
为了让页面在各不同浏览器之间显示效果一致,CSS样式清除和重置是前端开发必需要...
台湾CN2服务器怎么选 ? 从事互联网行业的朋友应该都清楚,租用海外服务器是拓展...
.tech域名 怎么备案的?. tech域名 备案,是指将网站在工信部系统中进行登记,相...
作者: Anna Monus 译者:前端小智 来源:blog.logrocket 点赞再看 ,微信搜索 ...
最近做项目发现引用图片时下方总出现空白,情况如下图所示。 style .img-box { b...
将Vue组件包装为本Web组件。 由于Angular支持使用自定义 Web组件 ,因此能够使用...
据爆料,3声母 域名 yzg.net被广州遇乐网络有限公司以3万元的价格收购,现已启用...
相信大家平时使用浏览器时遇到过点击一个链接或者按钮,浏览器会询问是否打开客...
Dw是我们设计网页的软件,这个软件功能很强大,今天小编就为大家介绍DW制作鼠标...