押注統一的工具鏈

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（每週 6900 萬次下載）、Vitest（3500 萬次）、Oxc（500 萬次）、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，我不會搬——除非那組版本號不再動得這麼急。

統一工具鏈這套說法一次又一次回來，是因為那堆組合爆炸只會愈長愈大。這一次，開口的人手上握住的零件，多到足以讓這話講得算數。至於它撐不撐得過生產環境的實戰，就是唯一值得盯住的問題。