一個工具，同時管住程式的「形」與「質」

前端專案傳統上需要兩套機制。一套維持外形一致，摺行、排序匯入；另一套維持意義誠實，指出沒用到的變數與可疑的判斷。實務上這意味著兩個套件、兩份設定檔、兩個編輯器擴充、兩組格式不同的錯誤訊息，還長期邀請這兩者在同一行上意見相左。現在它們被收進同一個執行檔：既能格式化也能檢查，裝一次，只讀一份設定。

血統這件事有助於理解它的野心。它延續的是一個更早的專案提出、卻始終沒能交付的統一工具鏈構想，而社群把這個概念接了下來，從公布到可用版本的路徑短得多。理念留了下來，交付則沒有卡住。

速度不是行銷數字

引擎以 Rust 撰寫，實務後果是存檔即格式化真的即時，按鍵與檔案被重寫之間沒有可察覺的停頓。大型儲存庫的全量檢查以秒計，而不是以「去泡杯咖啡」計，這件事會改變行為：你會一直跑它，而不是留到提交前才跑。持續整合的等待時間下降得既好量測、又難以爭辯。

相容性下的功夫類似。輸出刻意對齊事實標準的格式化結果，老專案遷移接近換一顆引擎，而不是重寫一遍；第一次跑出來的差異量小到審查者真的讀得完。這個細節比任何功能清單更能決定採用與否，因為一場產生上萬筆無關變更的遷移，無論工具多快都會被否決。

規則庫持續擴充，框架專屬的檢查也穩定補上。診斷會附上原始碼範圍、建議修法與穩定的規則名稱，對那些刻意抑制某些規則、又希望抑制能撐過升級的團隊來說，這一點很關鍵。主流編輯器都有整合，語言伺服器的表現像個現代工具，而不是帶著意見的語法上色器。

它不見得是顯而易見的答案

檢查設定高度客製、裝了幾十個社群外掛、還自己寫規則的專案會遇到缺口，而那些規則得重寫是實打實的工作。非常老舊的程式庫，或檔案佈局特殊的專案，可能需要它目前還表達不順的設定。如果一個團隊已經愉快地標準化在舊的那一對工具上、也沒有抱怨，切換的成本大於回收。

新專案的情勢不同：沒有東西要遷移，設定就是一份短短的檔案，預設規則集是合理的起點，而不是一份得先修剪才有用的清單。這正是它被設計出來的情境，而這也是今年新開專案裡很大的一塊。

它指出了前端工具鏈收斂的方向：與其讓開發者維護一堆各懷心思的小工具，不如給一個又快又好的實作，把時間還給寫程式。

怎麼無痛採用。新專案從預設開始，第一天就把設定提交進版本庫，這樣審查時沒人會為風格爭論。既有專案先遷移格式化，把它落成一個機械性的提交、讓審查者可以整批跳過；再逐步啟用檢查規則，按目錄修而不是一次全修。持續整合裡掛上增量檢查，債務才不會長回來；要抑制規則請寫上註解與理由，而不是把整個類別關掉。

最後一句關於紀律：格式化的價值在於沒有人再討論格式。如果工具裝了，團隊卻還在拉取請求裡辯論行寬，那技術問題解決了，社會問題還沒有。