標題：Vite vs Webpack
日期：2022-06-06 10:28:00
toc：false
index_img：https://puep.qpic.cn/coral/Q3auHgzwzM4fgQ41VTF2rF1YCFdibQ9cyYktsNibicoKDA3PQPcYXddjA/0
類別：
- 前端
標籤： - 專案
- 檔案
- 使用者
- 服務
- 解決
- 出現
- 列印
Vite 為什麼快？#
當我們使用 webpack 進行專案建構時，應該都遇過這樣的情況。
假設我們的專案中有 A、B 兩個頁面。
其中 A 頁面是專案首頁，裡面的程式碼一切正常。
B 頁面是一個需要經過跳轉才會進入的頁面，裡面存在一些錯誤。例如：我匯入一個不存在的檔案
a.js然後列印a當我們建構這個專案時，明明我們從來都沒有進入過 B 頁面，但是此時 webpack 依然會給我們拋出一個對應的錯誤
Can't resolve './a.js' in xxx
出現這個問題的原因就是因為 webpack 的建構機制導致的。
在開發時建構時，webpack 預設會去 擷取並建構你的整個應用，然後才能提供服務 ，這就導致你的專案中，存在的任何一個錯誤（哪怕這個錯誤是在使用者從來都沒有進入過的頁面中出現的），它依然會影響到你的整個專案建構。
也正是因為這個原因，當你的專案越大時，建構的時間就會越長 ，你的專案啟動速度也就會越慢。
但是對於 vite 而言，我們進行同樣的測試，會發現一個很有趣的事情。
同樣的
Can't resolve './a.js' in xxx錯誤，在我們沒有進入到 B 頁面的時候，它是不會出現的，只有當我們進入了 B 頁面，才會突然出現這樣的一個錯誤。
而之所以會這樣的原因就是因為： vite 不會在一開始就建構你的整個專案 ，而是會將應用中的模組區分為 依賴 和 原始碼（專案程式碼） 兩部分，對於 原始碼 部分，它會根據 路由來拆分 程式碼模組，只會去建構一開始就必須要建構的內容。
同時 vite 以 原生 ESM 的方式為瀏覽器提供原始碼，讓瀏覽器接管了 打包 的部分工作。
因為這樣的機制，無論你的專案有多大，它只會建構一開始必須要建構的內容，這就讓 vite 在建構時的速度大大提升了。
這也是 vite 為什麼會快的一個核心原因。
Vite 這種機制會存在問題嗎？#
如果大家對 ESM 的建構機制有了解的話，那麼應該可以發現一個問題。
那就是 vite 既然以 原生 ESM 的方式為瀏覽器提供原始碼，讓瀏覽器接管了打包的部分工作 ，那麼假如我們的專案中存在 commonJS 的內容怎麼辦？是不是就意味著無法解析呢？
是的！
在 vite 的早期版本中，確實存在這個問題，這個問題導致的最核心的麻煩就是很多的 依賴 無法使用。
例如 axios 因為 axios 中使用了很多的 commonJS 規範，這就讓 vite 無法解析對應的內容（對應的 issue），從而會拋出一個錯誤，關於這個問題曾經也在 vite 的 issues 中進行過激烈的討論。
尤大也對此進行了發言：
那麼這樣的問題最終是怎麼解決的呢？
官方如何解決這種問題？#
因為這個問題非常嚴重，所以針對於這個問題，vite 在後期提供了 依賴預建構 的功能，其中一個非常重要的目的就是為了解決 CommonJS 和 UMD 兼容性 問題。目前 vite 會先將 CommonJS 或 UMD 發布的依賴項轉換為 ESM 之後，再重新進行編譯。這也可以理解為 速度對業務的一個妥協 。