Vite 3.0发布：回顾与展望.pdfVIP

深入浅出Vite

结束语：课程回顾和未来展望

发布于2022-05-09

在2021年2月，尤大正式推出了Vite2.0版本，可以说是Vite的一个重要转折点，

自此之后Vite的用户量发生了非常迅速的增长，很快达到了每周100万的npm下载

量。同时，Vite的社区也越来越活跃，目前已经形成非常庞大的社区生态(详情可见

Github地址)，给整个前端领域带来了诸多的改变，如:

Nuxt3、SvelteKit、Astro、StoryBook等在内的各大前端框架已经将Vite作为内

置的构建方案。

基于Vite的测试工具Vitest诞生，成为替代Jest的新一代测试方案。

如今已经2022年7月，距离v2版本已经发布了16个月的时间，Vite正式推出3.0

版本，接下来就给大家介绍一下Vite3.0带来的一些改变以及未来的规划。

一、全新的VitePress文档

对于用户侧来说，谈到框架的更新，文档自然是最重要的部分。现在你可以直接

去vitejs.dev站点体验到v3版本的文档，目前文档同样是使用VitePress进行搭建。

下面是暗黑模式下的一张截图:

怎么样，是不是比以前更加好看了呢？

不光是Vite，也有Vite生态中其它的一些项目使用VitePress进行文档站点的搭建，比

如Vitest,vite-plugin-pwa以及VitePress自身的文档，我也十分推荐大家使用

VitePress作为自己的文档建站方案之一。

如果你需要查看Vite2.0的文章，也可以访问v2.vitejs.dev。

二、开发阶段的更新

1.CLI的更新

在执行vite命令启动项目时，终端的界面和之前会有所不同，而更重要的是，为了避

免Vite开发服务的端口和别的应用冲突，默认的端口号从之前的3000变成了5173。

2.开箱即用的WebSocket连接策略

Vite2中有存在一个痛点，即在存在代理的情况下(比如WebIDE)需要我们手动配置

WebSocket使HMR生效。目前Vite内置了一套更加完善的WebSocket连接策略，

自动满足更多场景的HMR需求。

3.服务冷启动性能提升

Vite3.0在服务冷启动方面做了非常多的工作，来最大程度提升项目启动的速度。

首先我们来盘点一下Vite2.x阶段服务冷启动的一些问题。

从Vite2.0到2.9版本之前，Vite会在服务启动之前进行依赖预构建，也就是使用

Esbuild将项目中使用到的依赖扫描出来(Scan)，然后分别进行一次打包(Optimize)。

这样会造成两个问题:

依赖预构建会阻塞DevServer启动，但其实不阻塞的情况下，DevServer也可以

正常启动。

当某些Vite插件手动注入了import语句，比如调用babel-plugin-import添加

importButtonfromantd/lib/button，就会导致Vite的二次预构建，因

为antd/lib/button的引入代码由Vite插件注入，属于DevServer运行时发现的

依赖，冷启动阶段无法扫描到。

所谓的二次预构建包含两个步骤，一是需要将所有的依赖全量预构建，二是由于依赖更

新，页面需要进行reload，加载最新的依赖代码。这样会导致DevServer性能明显下

降，尤其是在新增依赖较多的场景下，很容易出现浏览器卡住的情况。因此二次预构建

也是需要极力避免的。当时vite-plugin-optimize-persist就是为了解决二次预构建带

来的问题，通过持久化的方式记录DevServer运行时扫描到的依赖，从而让首次预构

建便可以感知到，避免二次预构建的发生。

到了2.9版本，Vite将预构建的逻辑做了一次整体的重构，最后的效果是下面这样的:

DevServer启动后预构建(Optimize阶段)在后台执行，也就是预构建不再阻塞

DevServer的启动，只需要等待Scan阶段完成，不过通常这个阶段的开销非常

小。

如果某些依赖是DevServer运行时才发现的，那么Vite会尽可能地复用已有预构

建产物，尽量不进行pagereload。

具体实现大家可以去查看这个PR

那问题就完全解决了吗？其实并不是，在某些场