webpack 打包项目迁移到 Vite 的实践记录

项目名称

webpack打包项目迁移到vite

团队名称

闪电突击队

团队负责人信息

Better（廖小新）

项目简介

把行E通门户和管理台前端项目打包由webpack迁移到vite

项目背景及目标

我们前端项目使用webpack打包时，需要把项目所有依赖打包构建完成后才能正常访问页面，项目文件和代码量比较小的时候，开发服务器启动速度还能接受，但是当我们构建越来越大型的应用时，需要处理的 JavaScript 代码量也呈指数级增长。包含数千个模块的大型项目相当普遍。我们开始遇到性能瓶颈 —— 使用 JavaScript 开发的工具通常需要很长时间（甚至是几分钟！）才能启动开发服务器，即使使用 HMR，文件修改后的效果也需要几秒钟才能在浏览器中反映出来。如此循环往复，迟钝的反馈会极大地影响开发者的开发效率和幸福感。 Vite 旨在利用生态系统中的新进展解决上述问题：浏览器开始原生支持 ES 模块，且越来越多 JavaScript 工具使用编译型语言编写。

项目痛点

缓慢的服务器启动

当冷启动开发服务器时，基于打包器的方式启动必须优先抓取并构建你的整个应用，然后才能提供服务。

Vite 通过在一开始将应用中的模块区分为依赖和源码两类，改进了开发服务器启动时间，使用webpack启动开发服务器可能需要几分钟，改用vite后，启动开发服务器只需要几十秒，甚至几秒，可以极大的提高开发服务器的冷启动时间

文件改动缓慢的更新

基于webpack打包器启动时，重建整个包的效率很低。原因显而易见：因为这样更新速度会随着应用体积增长而直线下降。

在 Vite 中，HMR 是在原生 ESM 上执行的。当编辑一个文件时，Vite 只需要精确地使已编辑的模块与其最近的 HMR 边界之间的链失活（大多数时候只是模块本身），使得无论应用大小如何，HMR 始终能保持快速更新。

实现目标

开发服务器启动时间从原来的5~6分钟时间，缩短到几秒钟
极大的缩短模块热更新（文件改动页面自动更新）时间

常见问题

webpack 起开发服务器到底慢在哪？

基于打包器的方式冷启动必须先抓取并构建整个应用才能开始提供服务，而 JavaScript 代码量随应用变大呈指数级增长，包含数千个模块的项目相当普遍；启动要 5~6 分钟，即使有 HMR，文件修改后的效果也要几秒才在浏览器反映出来，反馈迟钝直接影响开发效率和幸福感。

Vite 为什么能把启动和热更新都压下来？

它一开始就把应用模块分成依赖和源码两类，开发服务器启动因此从几分钟降到几十秒甚至几秒；HMR 跑在原生 ESM 上，编辑一个文件时只需让已编辑模块与最近的 HMR 边界之间的链失活，大多数时候就是模块本身，所以更新速度不再随应用体积线性下降。

这次迁移定的是哪两个目标？

实现目标写了两条：开发服务器启动时间从原来的 5~6 分钟缩短到几秒钟，以及极大缩短模块热更新即文件改动后页面自动更新的时间。项目范围是行E通门户和管理台这两个前端项目的打包从 webpack 换到 vite，由闪电突击队做，负责人是 Better（廖小新）。