vite 是新兴的构建工具，它相比 webpack 最大的特点就是快。
那它是如何做到这么快的呢？
因为 vite 在开发环境并不做打包。
我们创建个 vite 项目：
bash
复制代码npx create-vite安装依赖，然后把服务跑起来：
bash复制代码npm install
npm run dev浏览器访问下：
本地是 main.tsx 引入了 App.tsx，并且还有 react 和 react-dom/client 的依赖：
用 devtools 看下：
可以看到，main.tsx、App.tsx 还有 react 和 react-dom/client 的依赖都是直接引入的，做了编译，但是并没有打包。
这是基于浏览器的 type 为 module 的 script 实现的：
我们加一个 index2.html：
html复制代码
Vite + React + TS
<script type="module" src="aaa.js"></script>
然后添加 aaa.js
javascript复制代码import { add } from './bbb.js'
console.log(add(1, 2));bbb.js
javascript复制代码export function add(a, b) {
return a + b;
}起个静态服务访问下：
bash
复制代码npx http-server浏览器访问下
http://localhost:8080/index2.html
可以看到，aaa 和 bbb 模块都被下载并执行了。
当然，我们没有做编译，如果有 ts 或者 jsx 的语法，需要做一次编译。
那我们是不是可以起个服务器，请求的时候根据 url 找到对应的文件，编译之后返回呢？
没错，如果你这样想了，那你也可以写一个 vite。
vite 在开发环境下就是起了一个做编译的服务器，根据请求的 URL 找到对应的模块做编译之后返回。
当你执行 npm run dev 的时候：
vite 会跑一个开发服务：
这个开发服务是基于 connect 实现的，vite 给它加了很多中间件来处理请求：
当你请求 index.html 的时候，它会通过 ast 遍历，找到其中所有的 script：
然后提前对这些文件做编译：
编译是通过不同插件完成的：
插件就是一个对象，它导出了 transform 方法的话，就会在 transform 的时候被调用。
比如图中有 css 插件来编译 css、esbuild 插件来编译 ts/js 等。
每个插件都会判断下，只处理对应的资源：
比如 vite:esbuild 插件，就是对 js/ts 做编译，然后返回编译后的 code 和 sourcemap：
还有个 import-anlysis 插件，在 esbuild 完成编译之后，分析模块依赖，继续处理其它模块的 transform：
这样，浏览器只要访问了 index.html，那么你依赖的所有的 js 模块，就都给你编译了。
这就是 vite 为什么叫 no bundle 方案，它只是基于浏览器的 module import，在请求的时候对模块做下编译。
但不知道大家有没有想过一个问题：
浏览器支持 es module 的 import，那如果 node_modules 下的依赖有用 commonjs 模块规范的代码呢？
是不是就不行了。
这种就需要提前做一些转换，把 commonjs 转成 esm。
还有一个问题，如果每个模块都是请求时编译，那向 lodash-es 这种包，它可是有几百个模块的 import 呢：
这样跑起来，一个 node_modules 下的包就有几百个请求，依赖多了以后，很容易就几千个请求。
这谁受的了？
所以我们要提前处理下，不但要把 node_modules 下代码的 commonjs 提前转成 es module，还有提前对这些包做一次打包，变成一个 es module 模块。
所以，vite 加了一个预构建功能 pre bundle。
在启动完开发服务器的时候，就马上对 node_modules 下的代码做打包，这个也叫 deps optimize，依赖优化。
如何优化呢？
首先，扫描出所有的依赖来：
这一步是用 esbuild 做的：
esbuild.context 和 esbuild.build 差不多的功能。
可以看到，用 esbuild 对入口 index.html 开始做打包，输出格式为 esm，但是 write 为 false，不写入磁盘。
有同学说，esbuild 支持 import html 么？
这里用到了一个 esbuild scan plugin：
vite 实现的，用来记录依赖的：
它会在每种模块路径解析的时候做处理，其中支持了 html 的处理。
这样用 esbuild 处理完一遍，是不是就知道预打包哪些包了？
我们在项目里引入下 dayjs 和 lodash-es 再试下：
依然给你一个不少的给分析了出来：
接下来调用 esbuild 打包就行。
但打包之前呢，还会对路径做扁平化，比如 react-dom/client 变成 react-dom_client
效果就是打包之后文件是平级的。
从每个依赖包作为入口打包，输出 esm 格式的模块到 node_modules/.vite 下。
之后还会生成一个 _metadata.json 文件写入 node_modules/.vite 下：
这样的：
这个 metadata.json 是干啥的呢？
看到这几个 hash 了么
vite 会在这些预打包的模块后加一个 query 字符串带上 hash，然后用 max-age 强缓存：
因为这些依赖一般不会变，不用每次都请求，强缓存就行。
但是在 lock 文件变化或者 config 有一些变化的时候也需要重新 build：
重新预编译，然后在资源请求时带上新的 query，这样就让强缓存失效了。
这里强缓存的用法很典型，面试官们可以记一下作为考点。
这样，vite 的开发服务的请求时编译，再就是预构建就都完成了。
有的同学可能会问，为啥预构建要用 esbuild 呢？
原因就是快：
vite 在 dev 时的核心原理我们理清了，但是在 build 的时候总要打包的吧。
那肯定，在 build 的时候 vite 会用 rollup 做打包。
那不会导致开发时的代码和生产环境不一致么？
不会。
能做到这一点也很巧妙。
看下 build 时的 rollup 插件：
是不是似曾相识？
对比下 dev 时跑的 vite 插件：
没错，vite 插件时兼容 rollup 插件的，这样在开发的时候，在生产环境打包的时候，都可以用同样的插件对代码做 transform 等处理。
处理用的插件都一样，又怎么会开发和生产不一致呢？
这也是 vite 的巧妙之处。
在 dev 的时候，它实现了一个 PluginContainer，用和 rollup 插件同样的参数来调用 vite 插件：
然后 build 的时候，可以把这些插件直接作为 rollup 插件用。
对了，vite 在 dev 的时候还支持热更新，也就是本地改了代码能够自动同步到浏览器。
这个就是基于 chokidar 监听了本地文件变动：
然后在模块变动的时候通过 websocket 通知浏览器端：
浏览器端接受之后做相应处理就好了：
我们改下 Aaa.tsx，可以看到浏览器端收到了 update 的 ws 消息：
收到消息之后，把模块换成这个新的，加上 timestamp 重新请求就好了：
总结
今天我们分析了下 vite 的实现原理。
它是基于浏览器的 type 为 module 的 script 可以直接下载 es module 模块实现的。
做了一个开发服务，根据请求的 url 来对模块做编译，调用 vite 插件来做不同模块的 transform。
但是 node_modules 下的文件有的包是 commonjs 的，并且可能有很多个模块，这时 vite 做了预构建也叫 deps optimize。
它用 esbuild 分析依赖，然后用 esbuild 打包成 esm 的包之后输出到 node_modules/.vite 下，并生成了一个 metadata.json 来记录 hash。
浏览器里用 max-age 强缓存这些预打包的模块，但是带了 hash 的query。这样当重新 build 的时候，可以通过修改 query 来触发更新。
在开发时通过 connect 起了一个服务器，调用 vite 插件来做 transform，并且对 node_modules 下的模块做了预构建，用 esbuild 打包。
在生产环境用 rollup 来打包，因为 vite 插件兼容了 rollup 插件，所以也是用同样的插件来处理，这样能保证开发和生产环境代码一致。
此外，vite 还基于 chokidar 和 websocket 来实现了模块热更新。
这就是 vite 的实现原理。
回想下，不管是基于浏览器 es module import 实现的编译服务，基于 esbuild 做的依赖预构建，基于 hash query 做的强缓存和缓存更新，还是兼容 rollup 的 vite 插件可以在开发服务和 rollup 里同时跑，这些功能实现都挺巧妙的。
作者：zxg_神说要有光 链接：
https://juejin.cn/post/7350936959059722280 来源：稀土掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。