跳轉到內容

為何選擇 Vite

隨著 Web 應用的規模和複雜度不斷提升,構建這些應用的工具也面臨著巨大挑戰。大型專案的開發者常會遇到開發伺服器啟動緩慢、熱更新遲鈍以及生產環境構建耗時長等問題。雖然每一代構建工具都在前代基礎上有所改進,但這些痛點依然存在。

Vite 的誕生正是為了解決這些問題。它沒有選擇在現有的構建方法上進行漸進式改進,而是重新思考了開發環境下的程式碼服務方式。自那時起,Vite 歷經多個重大版本的更迭,每一次都適應了生態系統中湧現的新能力:從利用瀏覽器原生 ES 模組,到採用完全由 Rust 驅動的工具鏈。

如今,Vite 為許多框架和工具提供了動力。它的架構設計旨在與 Web 平臺共同演進,而非鎖定在某種特定的方法上,這使其成為一個可以長期依賴的堅實基礎。

起源

Vite 最初建立時,瀏覽器剛開始廣泛支援 ES 模組 (ESM)。這是一種無需預先使用打包工具將所有檔案合併,即可直接載入 JavaScript 檔案的方式。傳統的構建工具(通常稱為打包器)在瀏覽器能夠顯示任何內容之前,需要先處理整個應用。應用規模越大,等待時間就越長。

Vite 採用了不同的策略,將工作分為兩部分:

  • 依賴項(那些幾乎不會改變的庫)會使用快速的原生工具進行預打包,因此它們可以瞬間就緒。
  • 原始碼(那些頻繁變更的應用程式碼)則透過原生 ESM 按需提供。瀏覽器僅載入當前頁面所需的內容,Vite 會在請求時對每個檔案進行轉換。

這意味著開發伺服器的啟動速度幾乎是瞬間完成的,無論應用規模大小。當你編輯一個檔案時,Vite 會利用原生 ESM 實現熱模組替換 (HMR),僅在瀏覽器中更新該模組,而無需重新載入整個頁面或等待重新構建。

Bundle based dev server entry ··· route route module module module module ··· Bundle Server ready

在基於打包器的開發伺服器中,整個應用必須在服務前先完成打包。

Native ESM based dev server entry ··· route route module module module module ··· Server ready Dynamic import (code split point) HTTP request

在基於 ESM 的開發伺服器中,模組是在瀏覽器請求時按需提供的。

Vite 並非第一個探索這種方法的工具。Snowpack 開創了非打包式的開發方式,並啟發了 Vite 的依賴預打包機制。WMR(由 Preact 團隊開發)啟發了適用於開發和生產環境的通用外掛 API。@web/dev-server 則影響了 Vite 1.0 的伺服器架構。Vite 在這些思想的基礎上,進一步將其發揚光大。

儘管非打包式的 ESM 在開發過程中表現良好,但在生產環境中直接使用卻效率低下,因為巢狀匯入會產生過多的網路往返次數。這正是為什麼打包在生產環境中依然必要,以實現更優的構建結果。

與生態系統共同成長

隨著 Vite 的成熟,各類框架開始將其作為構建層。基於 Rollup 慣例的外掛 API,使得框架無需繞過 Vite 的內部結構即可實現自然整合。NuxtSvelteKitAstroReact RouterAnalogSolidStart 等框架都選擇了 Vite 作為其底層基礎。VitestStorybook 等工具也構建於此,擴充套件了 Vite 在應用打包之外的應用場景。像 LaravelRuby on Rails 這樣的後端框架也集成了 Vite,用於管理其前端資源管道。

這種增長並非單向的。生態系統塑造了 Vite,正如 Vite 塑造了生態系統。Vite 團隊執行著 vite-ecosystem-ci,針對每一次 Vite 的程式碼變更對主流生態專案進行測試。生態系統的健康不是事後補救,而是釋出流程的一部分。

統一的工具鏈

Vite 最初在底層依賴兩個獨立的工具:用於開發環境快速編譯的 esbuild,以及用於生產環境深度最佳化的 Rollup。這雖然可行,但維護兩條流水線導致了不一致性:不同的轉換行為、兩套獨立的外掛系統,以及為了保持對齊而不得不編寫的粘合程式碼。

Rolldown 的出現正是為了將兩者統一為一個打包器:它使用 Rust 編寫以實現原生速度,併兼容生態系統已經依賴的相同外掛 API。它利用 Oxc 進行解析、轉換和壓縮。這為 Vite 提供了一個端到端的工具鏈,使得構建工具、打包器和編譯器可以共同維護並作為一個整體演進。

結果就是從開發到生產擁有一套連貫的流水線。遷移過程非常謹慎:首先發布了技術預覽版,以便早期採用者驗證變更;透過生態系統 CI 及早捕獲相容性問題;並透過相容層保留了現有的配置。

Vite 的未來方向

Vite 的架構將持續演進,以下幾個方面正在塑造其未來:

  • 全打包模式:Vite 建立時,非打包式的 ESM 是最佳權衡方案,因為當時沒有工具既能滿足極速,又具備開發環境所需的 HMR 和外掛能力。Rolldown 改變了這一現狀。由於極其龐大的程式碼庫可能會因大量的非打包網路請求導致頁面載入緩慢,團隊正在探索一種模式,讓開發伺服器像生產環境一樣對程式碼進行打包,從而減少網路開銷。

  • 環境 API:不再將“客戶端”和“SSR”視為僅有的兩個構建目標,環境 API (Environment API) 允許框架定義自定義環境(如邊緣執行時、Service Worker 等其他部署目標),每個環境都有各自的模組解析和執行規則。隨著程式碼執行的位置和方式日益多樣化,Vite 的模型也將隨之擴充套件。

  • 與 JavaScript 同步演進:隨著 Oxc 和 Rolldown 與 Vite 的緊密協作,新的語言特性和標準可以快速在整個工具鏈中採用,無需等待上游依賴的更新。

Vite 的目標不是成為終極工具,而是成為一個能夠與 Web 平臺以及構建於其上的開發者們一同持續演進的工具。