在以前，我们已经习惯了基于纯打包的开发方式，但是这种方式在实现过程中会有很多问题。首先，打包就意味着整个应用需要先打包好，浏览器和服务器才能启动，然后才能看到效果；其次，当应用中有很多的依赖时，初始化打包过程就会变得异常缓慢。
Vite基于此现状了一些改变，首先，它把整个应用拆分成了源代码层和依赖层，只要版本锁定，依赖里的代码就不会变，也就没有必要做热更新、保留细粒度的模块，Vite完全舍弃了对依赖的频繁处理过程。如果依赖很大，使用第三方打包器耗时会很久，而采用原生代码写的JS打包器，比如 esbuild，就可以快几十倍；其次，对于源代码，则是通过原生 ES modules 来做热更新，确保热更新的速度跟项目大小解耦（当然初次启动的速度还是会跟项目大小挂钩）。
回头看去年的时候，Vite势头正足，尤大曾多次在各个社区论坛表示过这个新的打包神器将会成为趋势，从谷歌搜索指数上来看在去年也确实非常活跃：
使用体验
我从 Vite2.0 开始使用在实际项目当中，由于当时负责的项目是saas系统中的一个新板块，可以允许我使用新技术来开发，于是就上了vite，不得不说开发体验是真的好，但由于项目本身是比较新的，依赖少，所以效率提升也不好说。
Vite 设计的初衷是改善开发时的反馈速度，虽然目标是改善体验，而不是干掉 webpack，但 vite 似乎从一开始就没想过如何让 webpack 用户很好的转移到 vite 的怀抱中来，对于旧项目我尝试过很多改造成 vite 的方法，社区的一些所谓一键 webpack 转 vite 的工具也尝试过，始终没办法很顺利地完全改造。由于 webpack 存在了多年，也处理过很多奇怪的特殊问题，对于特别复杂、深度定制的场景都自成一套体系，而 vite 没有任何办法去解决每一个 webpack 要解决的问题，所以一个项目经历的时间越长，改造工程就越大，vite 只是把大部分用户要面对的问题，做得更简单更快而已，它不是不想取代 webpack ，而是不可能取代，至少现在还不能。
既然无法完全迁移到 vite 体系，能不能用 vite 改变开发体验，打包则还是使用 webpack 呢？我认为可以但没必要，如果人人都这么做，也势必会阻碍 vite 生态的发展，目前 vite 跟 webpack 一样依赖插件来处理复杂问题与场景，只不过 webpack 存在时间更长久，所以相对插件支持才更加丰富。一开始我在项目中打算兼容两种模式，在保留 webpack 的情况下使用 vite 进行开发，但开发过程中就要需要费力地去考虑两头是否存在差异，比如说资源打包两边的写法就不一样，webpack 支持使用 require 导入资源而 vite 需要用 import 的写法，还有比如 node 环境的 process.env 变量在 vite 中无法轻易获取到，需要做些兼容处理等等，最终还是放弃了 webpack，怕使用 vite 开发自测完没问题的功能，等下用 webpack 打包却出了问题，那不是搬起石头砸自己的脚嘛。
在webpack中一般使用require('@/assets/xxx.png')来引用资源，在vite中可以用await import('@/assets/xxx.png')来引用图片或资源。
至于打包的话，vite 打包工具使用的是 rollup，打包速度上与 webpack 相比没有什么优势，但也没有劣势，顺带提一嘴，如果公司不是技术驱动型的，领导会更优先考虑生产的效率，而不是开发的效率，vite 提升的是开发体验，但对项目部署上线并无提升，回归到标题，我觉得尤大只说对了一半，确实有很多人开始用 vite，但很多人其实还是抛弃不了 webpack。
一些常用的 vite 配置：
import viteCompression from 'vite-plugin-compression' // 打包优化 gzip 压缩
// 全局样式： css: { preprocessorOptions: { less: { modifyVars: { color: `true; @import "./src/assets/styles/color.less";`, }, }, }, },// 配置node进程变量 define: { 'process.env': process.env, },
总结
- 新项目，vue3体系则首选vite。
- 旧项目，且依赖包很多，还是建议不要迁移到vite，成本太高。
- 大型项目，如果有采用微前端架构，可以在子系统使用vite构建项目提升开发体验，无论子系统是不是vue项目。
