前言

前幾天在 ViteConf 2024 時，Evan You 宣佈成立一間新公司 — void(0)，目標在打造一整套開源、統一、高效能的 JavaScript 開發工具鏈。

雖然前面 Day 18 有點到一些，但今天在看完了這場 keynote 與後面 Oxc 專案的核心開發者 Boshen 的介紹後，認為核心開發團隊經過一年的研究後講的又更清楚了，因此也做了些筆記，那就讓我們快速了解一下這個 Oxc 跟這個 void(0) 是怎麼回事吧。

什麼是 void(0)？

Vite 現在的缺點與困境

雖然 Vite 生態系四年來成長速度很快，但這兩年都不斷提到目前有一些痛點：

• esbuild 在 dev 中被拿來當 dep. pre-bundling (或稱 dep. optimizer) 的打包，但它在 code splitting、tree-shaking、plugin 的不足讓 Vite 無法完全用它做為統一的 bundler
• Rollup 打包速度太慢
• Rollup 目前底層用上的 SWC 有執行檔過大的問題，舉例在 macOS 上 SWC 的 binary 檔案有 37MB，幾乎是 Vite 本身的兩倍多。且 SWC 本身也沒有提供完整的 bundler 功能。
• esbuild 與 Rollup 兩套 bundler 造成 dev / prod 行為不一致，有時會在上線後才發現 bug
• 多套的工具造成 build pipeline 的過程中轉譯語言成本的浪費：
  • 同樣一段程式碼，在 Vite 做 production build 時重複被解析成 AST、轉譯、序列化成字串
  • 這些資料在這三個工具的原生執行環境中傳輸，像是從 Go process 傳到 JS main thread，再傳到 Rust，再傳回 JS，中間的轉換過程浪費成本
  • 如果開啟 source map 的功能後上述的狀況會更糟糕，因為在每一步傳輸中都會需要重新映射（remapping）這些 source map 再去做合併

💡 補充：SWC 筆記

參考 SWC 官網介紹，整理一下筆記：

• 可以理解為更快的 Babel
• 因為是以 Rust 為基底做開發，比 Babel 快 20~70 倍 (隨著編譯時使用的硬體資源提升有所不同)
• 用途
  • 主要用來轉譯 JS/TS 成瀏覽器可識別的一般 JS
  • minification
  • 可與 webpack 搭配 (swc-loader)
  • 可用來增進 Jest 效能 (@swc/jest)
• 一些應該不太重要的業界冷知識
  • SWC 原作者是個 1997 的韓國小哥 DongYoon Kang (kdy)
  • Next.js 12 的文章中提到，目前 Vercel 已挖角了 SWC 作者 kdy 及 Parcel 核心貢獻者 Maia Teegarden，決心投資 Rust 生態系

為什麼要成立 void(0)？這是什麼？

綜上所述的問題，去年 Vite 團隊決定與 Rspack 團隊一同開發 Rolldown，但當團隊越鑽越深時，發現如果不一次做到好，底層的這些問題可能仍會歷史重演，JS 生態系的底層仍需要同時仰賴多套工具。

所以決定不要只停在統一 bundler 這一步，想要將底層工具鏈也全部串起來，也因此募資並成立了 void(0) 這間公司想打造一個全方位的 JS 工具鏈，希望能達到這樣的願景：

• 統一 (Unifoed)：希望能在 dev / prod 轉換程式碼時都使用同一套工具、使用相同的 AST、同樣的設定、同樣的模組格式、路徑解析方式
• 高效能 (High Performance)：做打包與轉譯等工作，應使用編譯型 (compiled-to-native) 語言，不僅可以增加 DX、加快產品交付，甚至能幫在座的各位省機器的成本
• 可組合 (Composable)：工具鏈中的每一段應要是可獨立使用的，像是 parser、resolver、transformer 等，應該都要是一個套件，不論是 NPM packages 或是 Rust crates
• 框架不可知論 (Runtime Agnostic)：這工具鏈應該不限制只能被用在某個框架中

什麼是 Oxc？

上面有看到在 Vite 的生態系中，Oxc 是一個可組合的語言工具鏈，其中含有一整套的 npm package 與 Rust crates，包含 parser、linter、formatter、transformer、minifier、resolver、semantic analysis 這些功能。

效能大比拼

或許你可能會對其中的這些工具感到困惑，直接看一下效能比拼中比對的對應工具，會看到一些熟悉的工具：

• Oxc parser 比 SWC 快 3 倍、比 Biome 快 5 倍
• Oxc linter (又稱 oxlint) 比 ESLint 快 50~100 倍，當今天能擴充更多 CPU 核心時還能更快
• Oxc resolver 比 webpack/enhanced-resolve 快 28 倍
• Oxc transformer
  • TypeScript/TSX 轉譯：比 SWC 快 4 倍、比 Babel 快 40 倍
  • React Refresh：比 SWC 快 6 倍、比 Babel 快 70 倍
  • 產出 TypeScript 的聲明檔 (.d.ts)：比 tsc 快 20~45 倍
• Oxc 比起 SWC 與 Babel 有更少的記憶體使用與更小的套件與執行檔大小

而其中仍然有幾個工具我沒很懂它的用途，也做一下筆記：

• Parser 會用來解析 JS、JSX、TSX 並能生成 AST (Abstract Syntax Tree 抽象語法樹) 供後續 bundler 做語法分析，像是進入點在哪、需要轉譯成什麼模組、tree shaking 等
• Resolver 用來解析 Node.js 的模組路徑
• Transformer 利用 parser 產出的 AST，分析並轉譯出需要的 JS 檔案

從上面這些比較，可以理解為 Oxc 的目標想把以前的一些工具像是 Babel、ESLint、tsc、prettier 等 JS 開發工具鏈用 Rust 改寫來做一個效能提速，基本上跟另外一個 Biome 是同樣的目標，都想以 Rust 來實現更快速的工具。

Oxc 進度

但比較可惜的是目前這個工具鏈還在開發中，目前只有其中幾個工具可使用，在想可能等它再穩定些再回頭來學習，目前只有在 Oxc playground 上玩過：

原本只是個 side project

補充一個可能不太重要的冷知識，Oxc 核心開發者 BoShen 在議程中提到，這個 Oxc 最一開始只是他基於學習 Rust 的 side project，先是學著用 JS/TS 如何寫出 parser、linter 等，再進階到做出一個 Rust 版的 oxlint 並發佈這個工具，而後來 Preact 作者 Jason、和 Evan 都嘗試將 oxlint 拿來替代原本的 Linter 發現在大專案中的效能節省了數倍，因此才有了今天的故事。

小結

今天透過觀看 ViteConf 2024 更了解到 void(0) 這個前陣子在社群上引起討論的消息，知道它旨在打造一個全方位的 JS 工具鏈，而其中的這個 Oxc 將在未來做為其他工具的底層，來提供可在所有框架間組合的 parser、linter、transformer 等工具。

也趁機會了解了這些底層工具的用途，如果有什麼問題也歡迎在下面留言告訴我，我們明天見！

文章同步發表於個人部落格