Vite的来历

在应用领域程序全力支持 ES 组件以后，JavaScript 并没提供更多原生植物监督机制让合作开发人员以组件化的形式展开合作开发。这也便是他们对 装箱 那个基本概念熟识的其原因：采用辅助工具截取、处置并将他们的源代码组件串连成能在应用领域程序中运转的文档。

由此可见，造成了许多杰出的装箱辅助工具，比如说webpack、Rollup、Parcel。但，长此以往合作开发构筑的应用领域愈来愈大，就不得已遭遇两个难题——采用 JavaScript 合作开发的辅助工具一般来说须要极短天数（即使是几秒钟！）就能开启合作开发伺服器。循环往复会很大的减少合作开发工作效率，和合作开发的安全感。

这时Vite就孕育出而生了，Vite或许能短时期内正式成为业内的新宠，意在借助生态系中的重大进展化解前述难题：应用领域程序已经开始原生植物全力支持 ES 组件，且愈来愈多 JavaScript 辅助工具采用校对型词汇撰写。

伺服器开启较慢和预览较慢

伺服器开启较慢

当冷开启合作开发伺服器时，如前所述装箱器的形式开启要优先选择截取并构筑你的整座应用领域，接着就能提供更多服务项目。

Vite 透过在一已经开始将应用领域中的组件界定为依赖和源代码两类，改进了合作开发伺服器开启天数。

1. 依赖大多为在合作开发时不会变动的纯 JavaScript。一些较大的依赖（例如有上百个组件的组件库）处置的代价也很高。依赖也一般来说会存在多种组件化格式（例如 ESM 或者 CommonJS）。
2. Vite 将会采用 esbuild 预构筑依赖。Esbuild 采用 Go 撰写，并且比以 JavaScript 撰写的装箱器预构筑依赖快 10-100 倍。
3. 源代码一般来说包含一些并非直接是 JavaScript 的文档，须要转换（例如 JSX，CSS 或者 Vue/Svelte 组件），时常会被编辑。同时，并不是所有的源代码都须要同时被加载（例如如前所述路由拆分的代码组件）。
4. Vite 以 原生植物 ESM 形式提供更多源代码。这实际上是让应用领域程序接管了装箱程序的部分工作：Vite 只须要在应用领域程序请求源代码时展开转换并按需提供更多源代码。根据情景动态导入代码，即只在当前屏幕上实际采用时才会被处置。

预览较慢

如前所述装箱器开启时，重建整座包的工作效率很低。其原因显而易见：因为这样预览速度会随着应用领域体积增长而直线下降。

一些装箱器的合作开发伺服器将构筑内容存入内存，这样它们只须要在文档更改时使组件图的一部分失活[1]，但它也仍须要整座重新构筑并重载页面。这样代价很高，并且重新加载页面会消除应用领域的当前状态，所以装箱器全力支持了动态组件热重载（HMR）：允许两个组件 热替换 它自己，而不会影响页面其余部分。这大大改进了合作开发体验 —— 然而，在实践中他们发现，即使采用了 HMR 模式，其热预览速度也会随着应用领域规模的增长而显著下降。

在 Vite 中，HMR 是在原生植物 ESM 上执行的。当编辑两个文档时，Vite 只须要精确地使已编辑的组件与其最近的 HMR 边界之间的链失活[1]（大多数时候只是组件本身），使得无论应用领域大小如何，HMR 始终能保持快速预览。

Vite 同时借助 HTTP 头来加速整座页面的重新加载（再次让应用领域程序为他们做更多事情）：源代码组件的请求会根据 304 Not Modified 展开协商缓存，而依赖组件请求则会透过 Cache-Control: max-age=31536000,immutable 展开强缓存，因此一旦被缓存它们将不须要再次请求。

一旦你体验到 Vite 的神速，你是否愿意再忍受像曾经那样采用装箱器合作开发就要打上两个大大的问号了。

源代码初识

先来看下源代码结构、比其他的webpack、Roullup之类的简洁明了许多，比较的清晰。

初始化流程

1.调用resolveConfig函数，解析合并各种配置。

2.初始化两个http connect伺服器。

3.创建插件容器 ，createPluginContainer方法，把插件的各个钩子函数串连起来，后续在请求处置的过程中直接执行挂载好的钩子函数。

4.生成两个server对象，包含配置信息、伺服器信息、一些辅助函数等。

5.配置一系列内置中间件，各个中间件做的事情，返回server对象。

调用 server 的 listen 方法

1.运转插件container的buildStart钩子，进而运转所有插件的buildStart钩子

2.展开依赖预构筑，运转runOptimize函数。

3.开启服务项目，监听端口。

构筑依赖

配置参数

exportinterfaceDepOptimizationOptions {/**
   * 入口文档，默认从html文档展开解析收集依赖，如果配置了的话，就从配置文档已经开始展开解析
   */entries?:string|string[]/**
   * 须要展开预构筑的文档
   */include?:string[]/**
   * 不须要展开预构筑的依赖
   */exclude?:string[]/**
   * 预构筑是透过esbuild展开的，所以能自定义配置esbuild参数
   */esbuildOptions?: Omit