押注統一的工具鏈

JavaScript 生態最典型的失效方式，是配置的組合爆炸。

每個項目都要在下面這堆東西裡各揀一個：{nvm, volta, fnm} × {npm, pnpm, yarn, bun} × {vite, webpack, turbopack, rolldown} × {eslint, biome, oxlint} × {prettier, biome, oxfmt} × {jest, vitest} × {turbo, nx, moon} × {tsc, tsgo}。每一個組合有自己的配置檔、自己的版本矩陣，還有自己在星期二下午出事的方式。團隊把真金白銀的工程時間，花在工具的樣板上面，不是花在產品上面。

統一工具鏈把這個組合壓成一個。Vite+——執行檔叫 vp，MIT 授權，出自 voidzero-dev——是至今野心最大的一個。

這是甚麼

一個執行檔，一份配置，一條升級路徑。那張取代表讀起來，幾乎就是過去五年前端折騰史的目錄：

底層那幾件用 Rust 寫的零件（Oxc、Rolldown、tsgo）撐起了宣傳數字：建置比 webpack 快 40 倍，Lint 比 ESLint 快 50 至 100 倍，格式化比 Prettier 快 30 倍。這些數字當成一個形狀來看，不要當成保證。真正值得留意的不是速度，是取代本身。

為甚麼這一次可能成事

統一工具鏈不是新事。Biome 論證過一個執行檔同時做 Lint 和格式化；Deno 由第一日起，就把運行環境、測試、Lint、打包捆在一起；Bun 在同一堆東西上，再加軟件包管理和運行環境。沒有一個真正在規模上取代到現存那一套。

規律是這樣：整合要行得通，前提是有一間機構掌握足夠多的底層零件，令跨工具的改動可以同步落地，而不是散落在一群各自為政的維護者手上。

Vite+ 是第一次，在 Vite 這個生態裡滿足到這個條件。同一間機構出品 Vite（每週六千九百萬次下載）、Vitest（三千五百萬）、Oxc（五百萬）、Rolldown 和 tsdown。每一件都已經在大部分生產環境的前端裡面跑着；vp 大致上只是在大家本來就在用的零件上面，加一層一致的 CLI。

這種對齊，扮不出來。這也就是整場賭注。

你放棄了甚麼

每一次整合都要付同樣的三筆代價，vp 不例外。

綁定。項目一搬上 vp，想換走其中一件，代價就是整條工具鏈。想用另一個測試執行器？那就離開了統一的升級路徑。賣點是「一套工具管全部」——那句話的另一面，是那隻戒指只戴得下一隻手指。

單點故障。vp 出一個 bug，開發、建置、測試、Lint、CI 會同時中招。用鬆散那一套，ESLint 出個回歸，星期一煩你一日，打包器星期二照樣出貨。用統一執行檔，爆炸半徑就是整條流水線。這件事本身沒問題——前提是你信任維護者的發佈紀律，程度等同你信任底下那幾件工具。

插件碎片化。Vite+ 統籌的那幾個經典生態，各自有自己的插件經濟。每一步整合都在問同一條問題：統一之後的工具，有沒有把鬆散那套本來就有的整合點暴露出來？而那些假設了可以直接存取的插件，會變成怎樣？老實的答案是：現在還未知。

甚麼時候值得下注

我判斷重寫用的那套診斷，套在工具整合上一樣合用。三條問題：

• 底下那幾件，你本來就在用嗎？如果你那套是 Vite 加 Vitest 加 tsc 加 Prettier，vp 大致只是一層 CLI 外殼，遷移風險很低。如果你在用 webpack、Jest 和一份自訂 ESLint 配置，那次遷移是一場改頭換面的重寫。
• 拿得到好處的最細範圍，是甚麼？在現有 monorepo 裡開一個新的軟件包，是一個乾淨的目標。整個 monorepo，而且在季度中途，不是。
• 出事的時候，工具鏈由誰負責？如果你有人肯在凌晨兩點讀源碼，統一執行檔沒有問題；如果答案是「等上游修」，那就是一項負債。

我一直回到同一個想法：工具要小，而且要長命。依賴愈少愈好，但每一項依賴都要自己撐得起自己的重量——而一件吸收了十件工具的工具，是一項依賴，帶着十件工具的表面積。Vite+ 的賭注是：由一隊人擁有這片表面積，會令它更容易讀得懂。這個講法說得通。但不是免費。

這一季，我會在一個全新的應用上跑 vp。一個六個人在用的生產環境 monorepo，我會等到版本號不再跳得那麼快，才搬。

統一工具鏈這個推銷會不斷回來，因為那個組合的重量不斷在長。今次不同的是，推銷的人手上握着足夠多的零件，講得出，也做得到。這套東西碰上生產環境之後撐不撐得住，是唯一值得追蹤的問題。