当我尝试着把老项目 Webpack 迁移到 Vite 时,发现并没有这么香

本文讲述了作者将一个前端项目从Webpack迁移到Vite的过程,探讨了Vite启动速度快的原因,详细记录了迁移中遇到的alias错误、less全局变量、DOM元素错误、typings找不到、svg识别、global未定义等问题及其解决方案,以及在开发、打包上线方面的思考。Vite借助esbuild预构建依赖,启动和热更新速度快,但生态尚不完善,适合作为开发辅助工具。
摘要由CSDN通过智能技术生成

如果对前端八股文感兴趣,可以留意公重号:码农补给站,总有你要的干货。

背景

最近,就前端开发过程中的痛点及可优化项做了一次收集。 其中,构建耗时、项目编译速度慢的字眼出现了好几次。

随着业务的快速发展,我们很多项目的体积也快速膨胀。随之而来的, 就是打包变慢等问题。

提升研发效率,是技术人永恒的追求。

我们项目也有启动慢的问题,同事也提到过几次。刚好我之前也做过类似的探索和优化, 于是就借这个机会,改造一下项目, 解决启动耗时的问题。

于昨天下午, 成功嵌入 Vite, 项目启动时间由约 190s => 20s, 热更新时间缩短为 2s。

中间踩了一些坑, 好在最后爬出来了, 相关技术要点都会在下文中呈现。

今天的主要内容:

  • 为什么 Vite 启动这么快
  • 我的项目如何植入 Vite
  • 改造过程中遇到的问题以及解决方式
  • 关于 Vite 开发、打包上线的一些思考
  • 相关代码和结论

正文

为什么 Vite 启动这么快

底层实现上, Vite 是基于 esbuild 预构建依赖的。

esbuild 使用 go 编写,并且比以 js 编写的打包器预构建依赖, 快 10 - 100 倍。

因为 js 跟 go 相比实在是太慢了,js 的一般操作都是毫秒计,go 则是纳秒。

另外, 两者的启动方式也有所差异。

webpack 启动方式

[9GQMK7]F7$UQ}9SRI(R7ML.png

Vite 启动方式

image.png

Webpack 会先打包,然后启动开发服务器,请求服务器时直接给予打包结果。

而 Vite 是直接启动开发服务器,请求哪个模块再对该模块进行实时编译。

由于现代浏览器本身就支持 ES Module,会自动向依赖的 Module 发出请求。

Vite 充分利用了这一点,将开发环境下的模块文件,就作为浏览器要执行的文件,而不是像 W ebpack 那样进行打包合并。

由于 Vite 在启动的时候不需要打包,也就意味着不需要分析模块的依赖、不需要编译。因此启动速度非常快。当浏览器请求某个模块时,再根据需要对模块内容进行编译。

这种按需动态编译的方式,极大的缩减了编译时间,项目越复杂、模块越多,vite 的优势越明显。

在 HMR(热更新)方面,当改动了一个模块后,仅需让浏览器重新请求该模块即可,不像webpack那样需要把该模块的相关依赖模块全部编译一次,效率更高。

从实际的开发体验来看, 在 Vite 模式下, 开发环境可以瞬间启动, 但是等到页面出来, 要等一段时间。

我的项目如何植入 Vite

新项目

创建一个 Vite 新项目就比较简单:

yarn create @vitejs/app

QBRE_05QJLGA_5P0J5%P{%8.png

生成好之后, 直接启动就可以了:

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值