Fri Jan 31 2025
...
FastComments TypeScript 遷移完成
! 本文包含技術術語
新的內容
在 FastComments，我們重視靜態類型語言。更具體地說，我喜歡具有良好型別系統和快速編譯器的語言。FastComments 是以後者開始的——或者說沒有編譯器。在第一年內，我們有兩個用現代 Java 編寫的服務，但主要的後端和前端庫是用在 Node 上運行的 CJS JS 編寫的。
為了迎接未來十年的開發，我們已經將最大的 FastComments 組件遷移到 TypeScript。
這涉及到超過 130,000 行代碼（其中 100,000 行是後端）跨越 1441 個文件，並修復了超過 8000 個編譯錯誤。
這是在兩週內完成的。
代碼凍結 - 謝謝你
我想感謝我們的客戶在我們進行為期兩週的代碼凍結以完成這次升級期間所帶來的任何延遲的錯誤修正或功能釋放。謝謝你！
修復的錯誤
如你所想，我們修復了一些錯誤。這些主要涉及垃圾郵件檢測和緩存。
重大變更
- 所有 API 端點現在返回 status: 'failed'，而不再是 "failed" 和 "failure" 的混合狀態值。"success" 保持不變。
- 如果沒有匹配，我們將不再默認於第一個小部件配置，而是返回默認系統配置。
過程如何？
我們發現，像往常一樣，NPM 生態系統中的許多工具在幫助進行此任務時並不太好用。因此，我們使用 LLM 生成腳本來完成許多工作。例如，我們大量使用 JSDoc，以便可以編寫腳本將 JSDoc 轉換為 TypeScript 接口和類型定義，並正確註解函數的參數和返回類型。我們還使用這些腳本從 CJS 遷移到 ESM，這包括重寫導入、導出，以及檢測常見的運行時問題，例如 __dirname。
我提到過運行時問題嗎？
2025 年的 TypeScript 如何？
TypeScript 是一種適合編寫業務邏輯的好語言。但 Java 的開發體驗仍然更好。如果 Java、Go 或 Rust 編譯，則很可能它會正常工作。使用 TypeScript，我可以這樣做：
console.log(__dirname);
...這將會編譯。
但在現代的 ES 模塊中，它卻無法運行。你的 IDE 甚至會高興地自動補全 __dirname，然後在運行時會報錯。這感覺就像 Spring DI，但更糟。
你也可以這樣做：
context.someImportantMethodToCall;
現在，這是一個「語句」。這是一個有效的「語句」。乍一看你可能會以為我們在調用 someImportantMethodToCall，但其實我們並沒有！至少我使用的 IDE 不會對此發出警告，編譯器也不會。這段代碼會什麼都不做（除非 someImportantMethodToCall 是一個類的 getter，在這種情況下它會被隱式調用...）
修復方法是：
context.someImportantMethodToCall();
我想你可能可以用類似 eslint 的東西和某個 "no no side-effects" 規則來檢測這一點，但這樣會引入另一大組庫需要不斷更新，然後 eslint 必須在每次構建時解析整個代碼庫，工具變得很慢，等等——不，謝謝。處理 eslint 這類慢工具的生產力影響在我過去的工作中比我從 eslint 修正/預防的小問題中所獲得的 "提升" 更顯著。現在出現了更快的替代方案，這是非常好的。
TypeScript 的優勢在於像 Pick<User, 'username', 'email'> 這樣的語言特性。這與類型推斷相結合，提供了一種從資料庫獲得型別安全的查詢結果的方式，適用於大型物件的子集，而無需為每個形狀定義一個類。Pick 是我驚訝於 Scala 沒有的東西。類型聯合也非常好。
增量構建的效果也相當不錯，我們在 CI 中的構建時間平均僅增加了大約 5 - 10 秒，用於構建共享庫、前端和後端。
開發時間表
對於好奇的人，這是我們的進展情況：
- 第一天：在 362 個文件中發現 5564 個錯誤。
- 第二天：在 239 個文件中發現 4034 個錯誤。
- 第三天：在 191 個文件中發現 3784 個錯誤。
- 第四天：在 169 個文件中發現 2974 個錯誤。
- 第五天：在 171 個文件中發現 3000 個錯誤。
- 第六天：在 165 個文件中發現 2916 個錯誤。
- 第七天：在 157 個文件中發現 2618 個錯誤。
- 第八天：在 109 個文件中發現 2253 個錯誤。
- 第九天：在 69 個文件中發現 1605 個錯誤。
- 第十天：在 53 個文件中發現 686 個錯誤。
- 第十一天：後端單元測試通過
- 第十二天：開始遷移前端，3118 個錯誤。
- 第十三天：發現 2172 個錯誤。
- 第十四天：發現 1224 個錯誤。
- 第十五天：發現 498 個錯誤。
- 第十六天：所有編譯錯誤修復。
- 第十七天：發布。E2E 測試通過。在意外的運行時問題中有 30 分鐘的停機時間。:)
未來
我們這麼做是為了支持未來十年的開發。系統現在足夠龐大，使用類型系統進行開發比不使用更快。
你還可以期待我們的 TypeScript 館庫在 NPM 上的改進，因為它已經開始改進，因為我們現在在我們的伺服器和客戶端代碼中正在使用該館庫。
我們還將很快直接從伺服器代碼發布生成的客戶端 SDK，這是這項努力的主要動機之一。
總結
和所有重大發布一樣，我們很高興可以花時間來優化、測試和正確發布這些變更。如果你發現任何問題，請在下面告訴我們。
乾杯！