前言
早在Taro3.5的版本發佈時，Taro團隊就表示將會在接下來的3.6版本落地對Vite的支持。
但在3.6的版本中根本就沒看到Vite的身影，隨着社區對Vite的呼聲越來越高，終於在Taro4.0beta版本中支持了這一功能！
目前 Taro 在 Vite 編譯系統適配方面，優先支持了小程序、H5 和鴻蒙三端。
但仔細一想🤔，H5支持使用Vite編譯可以理解，但小程序是隻支持CommonJS模塊化規範並且不支持從不支持從網絡中加載 JS 資源，而Vite的優勢是在於它基於ESM的模塊化規範從而實現的no-bundle，極大地提升了前端項目的構建性能。
這麼看來，Vite在本地開發時直接利用ESM實現的無打包（no-bundle）構建優勢，在小程序開發中難以直接發揮。那麼Taro團隊又是如何處理的呢？
體驗
由於該功能還處於測試階段，所以我們現有的腳手架還暫時不能初始化vite版本的taro項目，需要安裝4.0版本的腳手架工具
安裝腳手架
npm i -g @tarojs/cli@beta⚠️需要注意的是：從4.0版本開始，將 Node.js v18 設置為長期支持的最低 node 版本
創建項目
taro init taro_project也可以跳過安裝 CLI 工具使用 npx 創建項目
npx @tarojs/cli@beta init taro_project
運行項目
接着我們來把項目運行起來看看與之前的webpack構建的有何不同
項目雖然是成功跑起來了，但感覺跟自己想象中的不太一樣呀？
- 啓動速度並沒有想象中的那麼快
- 編譯產物看着跟
webpack差不多，引以為傲的no_bundle呢？ - 怎麼還是CommonJS，看來還是繞不開小程序的限制
對於Vite的支持Taro4到底做了什麼？
在Taro的rfc中有着關於Vite的記錄:
那説白了Taro支持Vite最大的收益者是H5而不是小程序，看到這裏估計很多人都會失望了，大家使用Taro的重心應該是在小程序而不是H5吧。
H5編譯邏輯
為了兼容 Taro H5 的編譯，只需要實現：編譯配置對齊、設置編譯 Entry、注入運行時代碼。其餘的工作交給瀏覽器和 Vite 處理，開發者就能擁有快速的項目啓動和更新體驗。
3.1 編譯配置對齊
Taro H5 主要使用了 Webpack 的 Resolve 配置，如 alias、mainFields 等，這些配置在 Vite 中都能找到對應。
3.2 設置編譯 Entry
對於Vite來説，開發環境下index.html就是項目的入口文件，我們可以使用 Vite 插件的 transformIndexHtml 鈎子在 index.html 中注入對 app.config 的引用：
<script type="module" src="./app.config.js"></script>3.3 注入運行時代碼
目前 Taro H5 使用了自定義的 Webpack Loader 去注入運行時代碼，從而實現頁面加載、組件渲染等功能。在 Vite 中可以使用 Vite 插件的 load 鈎子達到同樣的目的。
小程序編譯邏輯
由於小程序不支持從網絡中加載 JS 資源，只能使用 Vite 的lib模式進行打包，輸出小程序規範下的四種產物：jsxmlcssjson。
與H5 一樣，使用 app.config 作為 Entry，輸出產物則使用小程序支持的 CommonJS 格式：
{
"build": {
"lib": {
"entry": "./app.config.js",
"formats": ["cjs"],
"fileName": "app.js"
}
}
}現在真相大白了吧，小程序只是使用了Vite的lib模式進行打包，那這跟直接使用rollup也沒啥區別😂
總結
從目前的版本來看，Taro支持使用Vite構建最大的受益者是H5而不是小程序，對於小程序的編譯也並不會快多少，從原理上看，現在想要使用Vite的核心功能似乎走不通，除非你能讓小程序作出改變，讓小程序支持從網絡中加載JS資源，但估計也不太可能，畢竟這一限制是出於安全考慮。
所以想要提升本地構建速度，可以考慮下這個方案：減少單次構建構建目標，具體操作可以參考之前寫的這篇文章：如何提升項目的本地構建效率？
Taro4.0正式版預計會在今年的Q2階段發佈，到時候再看看會不會有驚喜吧！
