開發者社群正在熱議一個名為 protobuf-ts-types 的新概念驗證庫，該庫利用 TypeScript 的模板字面量型別從 Protocol Buffer（protobuf）訊息定義中推斷 TypeScript 型別，而無需程式碼生成。儘管技術上令人印象深刻，但這種方法引發了關於將 TypeScript 型別系統推向極限的實際影響的爭論。
TypeScript 型別系統作為解析器
這個庫由開發者 Nathan Leung 建立，使用 TypeScript 的模板字面量型別直接在型別系統內解析 protobuf 訊息定義。這種方法消除了使用 protobufs 時通常需要的單獨程式碼生成步驟。該實現非常簡潔，有評論者指出，「原始碼如此之小真是太瘋狂了。我本以為會看到一個在型別中實現的龐大而複雜的解析庫。」
這種方法特別有趣的地方在於它展示了 TypeScript 型別系統不斷增長的能力。該庫本質上完全在 TypeScript 的型別系統內實現了一個解析器，展示瞭如何在型別級別使用模板字面量型別進行復雜的字串操作。
效能問題和實際應用
儘管取得了技術上的成就，許多開發者對這種方法的實際應用表示擔憂。討論中提出的主要問題是對編譯時間和開發者體驗的效能影響。
「模板字面量型別的靈活性確實很棒，但我無法想象在生產應用程式中使用這種奇技淫巧，拖慢編譯時間。」
多位評論者都表達了類似的擔憂，他們擔心在實際專案中使用如此複雜的型別級操作會影響 IDE 響應速度和構建效能。雖然小型示例可能表現良好，但幾位開發者指出，在更大的程式碼庫中，這種方法可能會顯著降低開發體驗。
侷限性和替代方法
該庫有幾個明顯的侷限性。它目前不支援服務、RPC、oneof 欄位、map 欄位或從其他 proto 檔案匯入。此外，它需要在 TypeScript 程式碼中內聯 proto 字串，這為跨多種語言維護 proto 定義創造了挑戰。
討論中的許多開發者建議，傳統的程式碼生成方法可能仍然更適合生產使用。程式碼生成工具建立靜態 TypeScript 型別，這些型別更容易被 IDE 處理，並且在開發過程中不需要複雜的型別級計算。
一些評論者還指出，對於僅使用 TypeScript 的專案，直接在 TypeScript 中定義型別可能比使用 protobufs 更直接，一位評論者表示他們更喜歡「在 TypeScript 中定義型別並從中生成 proto，因為 TypeScript 型別系統比 Protobuf 系統強大得多」。
protobuf-ts-types 的主要侷限性
- 不支援
service和rpc（僅支援message） - 不支援
oneof和map欄位 - 不支援 proto 檔案之間的
import匯入 - 需要在 TypeScript 程式碼中內聯 proto 字串
- 可能影響大型專案中的 IDE 效能和編譯時間
- 僅為概念驗證，尚未準備好用於生產環境
TypeScript 型別系統的演變
圍繞這個庫的討論突顯了 TypeScript 生態系統中的一個更廣泛的趨勢：型別系統越來越被用作一種獨立的程式語言。幾位評論者將其與其他超程式設計系統進行了類比，一位指出「我們花費所有這些努力將預處理器的型別系統轉變為圖靈完備的元語言」。
這種演變既有支持者也有批評者。支持者欣賞高階型別特性在描述複雜 JavaScript 模式時帶來的靈活性和強大功能。批評者則擔心型別系統變得過於複雜，導致令人困惑的錯誤訊息和糟糕的開發者體驗。
一個提到的潛在未來改進是 TypeScript 可能支援標記模板字面量中的型別推斷，這將允許在使用嵌入式領域特定語言（如 protobuf 定義）時有更優雅的語法。
總之，雖然 protobuf-ts-types 展示了 TypeScript 型別系統能力的令人印象深刻的技術成就，但社群對於這種方法是否適用於日常開發仍存在分歧。該專案既是一個引人入勝的概念驗證，也是關於 TypeScript 發展方向的對話起點。