大家好，我是 CUGGZ。

ViteConf 2022 于 10 月 11 - 12 日舉行。Vue 和 Vite 的作者尤雨溪發(fā)表了名為《How Vite Came to Be》的主題演講。下面就來回顧一下這場演講，看看 Vite 是如何誕生的！

下面先來回顧一下在這些構(gòu)建工具出現(xiàn)之前是如何編寫 Web 頁面的。

IIFE

Web 開發(fā)早期，我們使用 JavaScript 的唯一方式就是在頁面中引入<script>標(biāo)簽，所有 JavaScript 都在一個共享的全局作用域中解釋執(zhí)行。默認的方式就是在一個文件中編寫所有業(yè)務(wù)邏輯：

<script src="app.js"></script>
<script src="module-a.js"></script>
<script src="module-b.js"></script>

當(dāng)業(yè)務(wù)變得復(fù)雜時，JavaScript 文件就會變得很臃腫，就要考慮把這些文件拆分成幾個小的文件。但當(dāng)時 JavaScript 并沒有模塊的概念，所有的文件都共享在全局作用域中，這時可能會使用 IIFE（立即執(zhí)行函數(shù)）來分離作用域，不過這樣仍需要通過全局作用域來進行通信，比如通過 window 對象：

;(function() {
  var localVar = 1
  window.App.foo = {
    // ...
  }
})()

AMD

之后，一些早期的框架和庫的作者就開始使用自己的模塊加載器，并嘗試將其標(biāo)準(zhǔn)化為 AMD，即 Asynchronous Module Definition（異步模塊定義），Require.js 就是 AMD 的一種。RequireJS 是在開發(fā)環(huán)境下及時加載和轉(zhuǎn)化模塊的，可以通過編寫插件來及時編譯代碼，它還支持通過打包命令來構(gòu)建生產(chǎn)項目。不過，RequireJS 所有的轉(zhuǎn)化都在瀏覽器端進行，在進行打包時，一些生產(chǎn)環(huán)境中不需要的代碼在瀏覽器端也會被打進生產(chǎn)包中。

CommonJS

在 Node.js 興起之后，CommonJS 模塊化規(guī)范就成為了 JavaScript 模塊的標(biāo)準(zhǔn)，并且影響至今。

browseify / webpack

因為開發(fā)者想要在瀏覽器端使用 Node.js 包，并且想要在瀏覽器和 Node.js 環(huán)境中使用同一模塊格式，所以就出現(xiàn)了模塊打包工具，例如 browseify 和 webpack。它們將 CommonJS 模塊組合到一個 bundle 中，然后在頁面尾部的 script 標(biāo)簽中進行引入。

2013年，尤雨溪開始編寫 Vue，并產(chǎn)生了編寫 SFC 的想法，就是將 template、script、style 編寫在一個文件中來定義組件?？梢酝ㄟ^編寫 loaders 來將這些格式轉(zhuǎn)化為可執(zhí)行的 JavaScript，這樣編譯的開銷也只會在構(gòu)建時產(chǎn)生，而不會影響運行時性能。

于是，尤雨溪就在 browseify 和 webpack 中分別編寫了轉(zhuǎn)化 SFC 的插件：vueify 和 vue-loader，這兩個插件至今仍然適用。

vue-cli

不過，這些構(gòu)建工具對于大多數(shù)開發(fā)者而言還是太底層了。當(dāng)越來越多的初學(xué)者嘗試使用這些構(gòu)建工具時，其實他們對于學(xué)習(xí)如何配置打包并不感興趣，而是習(xí)慣于有一個入口來快速啟動。

于是在2015年，尤雨溪做了 vue-cli，這是一個基于 Webpack 構(gòu)建的 Vue 腳手架。vue-cli 做了很多如今已經(jīng)成為標(biāo)準(zhǔn)的工作，例如預(yù)配置，即大部分通用功能可以開箱即用。為了達到這樣的配置效果，基于webpack進行構(gòu)建還是有很大工作量的，并且還要兼顧不同的配置，例如，是否使用 TypeScript，使用哪個測試庫來運行測試用例，以確保這些配置項的不同組合可以正常運行。

除了 vue-cli，create-react-app（React官方腳手架）也使用了相似的配置來處理。值得一提的是，parcel 是第一個提出零配置概念的構(gòu)建工具。

ES Modules

2015年，JavaScript 終于推出了自己的模塊化標(biāo)準(zhǔn) ES Modules。從某種程度上說，Vite 正在幫助 JavaScript 生態(tài)系統(tǒng)轉(zhuǎn)向并收斂到 ESM 模塊規(guī)范。

隨著 ESM 的推出，基于 ESM 的構(gòu)建工具出現(xiàn)了。Rollup 是第一個基于 ESM 的打包工具，ESM 是其唯一的模塊標(biāo)準(zhǔn)，這讓 Roolup 的核心代碼非常簡潔高效，但是，Roolup 并不支持熱更新。所以，主流的解決方案，比如 Next.js、create-react-app、vue-cli 都是基于 webpack 的，因為用戶更注重?zé)岣碌拈_發(fā)體驗。

原生 ESM

2017年，瀏覽器終于支持了原生 ESM，這意味著以后可以在瀏覽器中直接使用 ESM 規(guī)范，而不是只能在構(gòu)建時才能使用。

使用原生 ESM 進行構(gòu)建并且使用 buildless 的方案會存在一些問題，因為有時候確實需要使用構(gòu)建工具，比如使用 SFC 時，轉(zhuǎn)化 TypeScript 時，使用 JSX、PostCSS 時，這些都需要一個構(gòu)建階段來進行處理。

原生 ESM 提供了 fetch 來進行 HTTP 請求，我們可以讓 dev server 無需任何轉(zhuǎn)化即可正常運行，并且這個 dev server 將會非常輕量，就像靜態(tài)文件服務(wù)器一樣。

@vue/dev-server

于是，在2019年，尤雨溪創(chuàng)建了 @vue/dev-server，它能夠進行轉(zhuǎn)化，并且使用原生 ESM 的 import 語法來加載  Vue 的 SFC 組件。然而，這存在兩個問題：

• 如何處理 npm 依賴。
• 如何在原生 ESM 中進行熱更新。

由于他一直忙于 Vue 3 的開發(fā)工作，就沒有持續(xù)跟進這兩個問題。

Vite 0.1

直到一年后，突然想到了如何在原生 ESM 中進行熱更新，然后就開始不斷編碼和測試。Vite 就正式誕生了，它能夠同時轉(zhuǎn)化并運行 Vue 的 SFC，并且能夠處理原生 ESM 的熱更新。第一個 release 版本的核心邏輯比較粗糙，并且僅支持 Vue組件，因為最初的想法是找到一個輕量的 vue-cli 的替代品。

Vite 0.2

Vite 誕生之后，下一步任務(wù)就是從概念驗證階段過渡到重構(gòu)階段。 在調(diào)研中發(fā)現(xiàn)，@web/dev-server 也是一個 bundless 的 dev你server。所以，當(dāng)時的想法就是創(chuàng)建一個支持原生 ESM 熱更新的 dev server。

調(diào)研之后，考慮僅把 Vite 作為 ESM 服務(wù)器的中間件來使用。但是從更深層次來看，有一個更宏大的愿景，就是把 Vite 作為一個開箱即用的工具，像 Vue 和 parcel 那樣。所以，如果僅把 Vite 作為 dev server 中間件就限制了它的發(fā)揮。

在使用完基于 Koa 的 es-dev-server 之后，最初的設(shè)想是每一個插件都當(dāng)做 Koa 的中間件來執(zhí)行。所以 Vue 轉(zhuǎn)變了思路，Vue 的插件將會是一個 Koa 中間件。

Vite 0.4

于是，在兩天之后，尤雨溪使用 JavaScript 實現(xiàn)了熱更新，這個過程需要處理通用的 JavaScript 邏輯，以及 npm 依賴的問題。當(dāng)時選擇了使用 Snowpack 1.0 來進行處理，而現(xiàn)在用 seinstall 代替了 Snowpack。Snowpack 1.0 是基于 Rollup 預(yù)配置實現(xiàn)的可以轉(zhuǎn)化 npm 包的工具，無論是什么格式，轉(zhuǎn)化為 ESM 之后都能在瀏覽器中正常運行。這就解決了各種模塊規(guī)范混用的問題，將它們統(tǒng)一轉(zhuǎn)化為 ESM 格式，這樣才能在瀏覽器中運行。

Vite 0.5

在 0.5 版本中，為了更好的輸出構(gòu)建產(chǎn)物，尤雨溪決定繼續(xù)在生產(chǎn)環(huán)境中使用 Rollup。Vite 成為了一個基于 Rollup 的熱更新 dev server。

VitePress

為了驗證這些插件和API是否是彈性并且可擴展的，來為更多的解決方案賦能，特別是在服務(wù)端渲染的場景下。所以，在 Vue 的生態(tài)中，提供了一個靜態(tài)站點生成器：VitePress，它是一個基于 Vite 的高級別應(yīng)用。它允許通過路由去編寫 HTML 文件，并且可以在其中引入 Vue 組件。VitePress 還可以用來生成文檔，并提供了服務(wù)端渲染的能力，它可以將 markdown 解析成 Vue 組件并編譯它，最后通過服務(wù)端渲染生成 HTML。

Vite 1.0 之前

在發(fā)布  Vite 1.0 之前， Vite 實現(xiàn)了和 vue-cli 相同的功能，吸引了越來越多的用戶，也因此發(fā)現(xiàn)了很多 bug，大多數(shù) bug 都和 npm 依賴以及模塊格式有關(guān)。在 2022年4月至11月期間，Vite 發(fā)布了 91 個 release 版本。

但是，最終 1.0 版本并未落地，因為在開發(fā) 1.0 時，尤雨溪意識到 Vite 并不僅僅是 vue-cli 的替代品，Vite 其實可以做兩件事：

• 作為與框架無關(guān)的最小配置打包工具來提供給用戶，這本質(zhì)上是一個更通用的 vue-cli，目的是讓每一個框架都能使用；
• 為框架作者提供一個共享工具層。這樣，對于使用 Nuxt.js、SvelteKit、Next.js 等框架的用戶，無需再重復(fù)造輪子，可以專注于更有意義的工作。

Vite 2.0

為了完成上述目標(biāo)，尤雨溪決定重寫 Vite。2020 年 12 月開始重寫 Vite 2.0。

• 首要目標(biāo)就是將 Vite 和框架解耦；
• 受到 WMR 啟發(fā)，選擇了通用 Rollup 兼容插件 API；
• 受到 SvelteKit 啟發(fā)，采用了全新的 SSR 運行時；
• 使用基于 esbuild 的依賴預(yù)打包方案，處理依賴的速度提升近百倍。

最終，在 2021 年 2 月 16日，Vite 2.0 正式發(fā)布。

組建團隊

尤雨溪的時間和精力被分散到了 Vite 和 Vue 兩個項目中，仍然需要確保 Vue 可以正常迭代。因此，在 2021 年 3 月正式組建團隊。目前，Vite 的絕大多數(shù)的日常維護工作都是由團隊成員完成的， 最近的 Vite 3.0 主要版本也是來自團隊成員的努力。

??相關(guān)資源??

• 演講PPT：https://docs.google.com/presentation/d/1O09rAOu_wRLHVjukVbBeSlRkLeX-dcYZfsdjPiU4kGQ/。
• 演講視頻：https://viteconf.org/2022/replay/vite_keynote。