押注統一的工具鏈

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 倍的打包、比 ESLint 快 50 到 100 倍的 Lint、比 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 搬上去——直到那組版本號不再動得這麼快。

統一工具鏈這個論點之所以一直回來，是因為那座組合爆炸的重量持續長大。這次，提出論點的這群人，擁有底下夠多的零件，讓他們講得算數。它能不能撐過正式環境的接觸，是唯一值得追蹤的問題。