2023 年 Web 工具的一大趨勢是使用 Rust 重寫現有工具。Rust 是一種出色的編程語言，能生成運行速度驚人的二進制文件，且與其它 Web 工具的互操作性極佳，這得益于 WebAssembly 的幫助。swc 和 Turbopack 等工具的速度提升為快速開發體驗帶來了巨大變革。

Biome、deno lint、Oxc 和 RSLint 等項目都有一個用 Rust 編寫的 JavaScript/TypeScript 代碼檢查器。對于那些對開發工具速度緩慢感到不滿的開發人員來說，以Rust（本機代碼）速度運行代碼檢查器，而非JavaScript（JIT腳本）速度，無疑是很有吸引力的。Prettier 甚至為 Biome 提供了 20,000 美元的獎金，以表彰其實現了與 Prettier 格式部分的 >95% 兼容性！

然而，基于 Rust 的 linters 是無法完全取代 ESLint 的。雖然性能優勢明顯，但也存在一個明顯的缺陷：類型檢查的 linting 功能缺失。

回顧：類型檢查的 Linting

傳統上，像 ESLint 這樣的 lint 工具一次只能檢查一個源代碼文件。這使得它們運行速度較快，理論上可以進行緩存和并行處理。

typescript-eslint 引入了使用類型信息的 linting 概念。通過調用 TypeScript 的類型檢查 API，lint 規則可以根據項目中的其他文件提供的類型信息，對代碼做出更加明智的決策。

類型檢查的 lint 規則可能比傳統的 lint 規則功能更強大。例如：

• @typescript-eslint/await-thenable ：禁止在非 Promise 值上使用不必要的 await 調用。
• @typescript-eslint/no-floating-promises ：可以提醒是否創建了一個 Promise 但忘記安全地處理它。
• @typescript-eslint/no-for-in-array ：用于標記對數組的不安全的 for...in 迭代（不是 for...of）。

這些規則只有在能夠使用類型信息來確定何時報告問題時才有實際用處。沒有類型信息，它們將無法理解從另一個模塊導入的值的類型。

類型檢查的 Linting 性能

類型檢查的 linting 相比傳統 linting 存在的主要劣勢在于性能。這是因為類型化的 lint 規則需要調用 TypeScript 等 API 來獲取類型信息，通常需要讀取所有文件以確定哪些文件會影響其他文件的類型。因此，類型檢查的 linting 性能通常會低于對整個項目運行 TypeScript 的性能。

TypeScript 本身也在不斷優化性能。例如，項目引用可以顯著幫助處理更大的項目。TypeScript 即將推出的獨立聲明模式看起來也可以顯著提高處理更大項目的性能。

但即使所有這些加速都完美地工作，類型檢查的 linting 設計上仍然比傳統的 linting 慢幾個數量級。因為從項目中推斷類型的過程本質上比傳統的 lint 規則一次只查看一個文件要慢得多。

大多數情況下，當看到類型檢查的速度慢的項目時，根本原因要么是 typescript-eslint 配置錯誤，要么是 TypeScript 類型慢。

基于 Rust 的代碼檢查工具和類型檢查

目前還沒有基于 Rust 的代碼檢查器與 TypeScript 的類型檢查 API 集成，這意味著基于 Rust 的代碼檢查器不能完全替代 ESLint + typescript-lint。

如果你不需要任何類型檢查的 lint 規則，那么可以切換到基于 Rust 的 linter。但強烈建議你至少查看 typescript-lint 中推薦的類型檢查規則，以了解缺少什么。

甚至可以同時運行這兩種工具：首先使用原生速度的 linter 快速反饋，然后僅使用 typescript-eslint 查看包含類型信息的規則。這個想法得到了多個原生速度 linter 維護者的支持：

• Biome 的 Emanuele 認為雙重 linting 是一種合理的策略。
• Oxc 的公告將 oxlint 描述為在 ESLint 過慢時的增強工具，而不是完全替代品。

這種互補而非取代的愿望部分源于這兩種 lint 工具在運作方式上的重大結構性差異。原生速度的 lint 工具尚未在其 lint 規則中實現類型檢查。下面來深入探討這一奇怪的功能差距。

集成類型檢查的 Linting 和基于 Rust 的 Linting

目前，TypeScript 的核心功能是為 TypeScript 編譯器和語言服務提供支持的代碼，它是唯一能夠為 TypeScript 代碼提供可靠類型檢查的組件。由于TypeScript是用TypeScript編寫的，因此其類型檢查以JavaScript的速度運行。

為了實現與 TypeScript 的類型檢查的集成，基于Rust的代碼檢查器面臨幾個選擇：

• 承受性能損失，調用TypeScript的JavaScript速度類型檢查API。
• 使用原生速度語言重新實現TypeScript的API。
• 將 TypeScript 的 API 提升到原生速度。

此外，基于 Rust 的 linter 不允許在 JavaScript 中編寫自定義 lint 規則。雖然這對大多數 JavaScript 生態系統來說是一個貢獻障礙，但這與本文的重點是兩個獨立的問題。

因此，將基于 Rust 的代碼檢查器與 TypeScript 的類型檢查集成在一起有不同的選項。

降低 JavaScript 速度

選擇這種性能影響方案可能會使基于 Rust 的 linter 速度降低到幾乎與 ESLint 無明顯性能優勢的程度。

以原生速度重新實現 TypeScript

對于 TypeScript 用戶來說，以原生速度重新實現 TypeScript 是一個極具吸引力的前景，而不僅僅是對于 linter。目前已有三個重要的嘗試：

• Ezno：一種類似于 TypeScript 的新語言，增加了依賴類型等特性。
• stc：一個可以替代 TypeScript 類型檢查的 Rust 編寫項目。
• TypeRunner：一個較早的嘗試，使用 C++ 編寫，但已不再積極開發。

需要注意的是，以新語言重新實現 TypeScript 是一項艱巨的任務。TypeScript 的類型推理需要處理泛型類型、協變、逆變等復雜邊緣情況，這是一項極具挑戰性的任務。這些項目目前都處于非常早期的階段，可能需要很長時間才能準備投產。

那是否可以通過縮小項目的范圍，只實現TypeScript的類型推理部分，從而降低這一選項的復雜性呢？對于 linters 來說，一個簡化版的TypeScript，跳過源代碼轉換、類型檢查可分配性錯誤等部分，只專注于編程類型檢查API，或許更為實用。例如，Oxc 項目已經成功地實現了一個 TypeScript 類型推理的簡化版，僅用幾千行Rust代碼就完成了這一任務。

然而，我們必須正視TypeScript背后有一個強大的開發團隊和社區支持的現實。TypeScript團隊由專業的編程語言專家組成，并且持續從社區中獲得貢獻。對于任何嘗試重新實現TypeScript的項目來說，跟上TypeScript的更新步伐是一項幾乎不可能完成的任務。盡管Ezno和stc等項目展現了令人印象深刻的成果，但它們作為獨立項目的長期可行性仍然充滿了不確定性。

將 TypeScript 的 API 提升到原生速度

為了提高TypeScript的性能，一個更具可行性的長期方案是優化其類型檢查器的運行速度。目前有幾種可能的解決方案：

• 將TypeScript的類型檢查器轉換為更高效的編程語言，如Go或Rust。這可以通過編寫一個轉換工具來實現，將TypeScript源代碼轉換為這些更快的語言。
• 對TypeScript進行預編譯和優化，類似于將其轉換為二進制格式。這種方法可以在編譯時對代碼進行優化，以提高運行時的性能。
• 利用Node.js的用戶快照技術來優化啟動時間。通過在啟動時預先優化代碼，可以加快冷啟動編譯器的速度。
• AssemblyScript和Static TypeScript是另外兩個有趣的探索方向，它們通過使用TypeScript的子集或修改版本來關注低級性能。

這些方案都面臨一定的挑戰，需要投入時間和資源進行開發。然而，通過持續優化和改進，可以逐步提高TypeScript的性能，使其更加適應快速發展的開發需求。

雖然可以通過各種方法來加速TypeScript的運行，但其實TypeScript本身的架構是阻礙性能提升的主要因素。它的代碼基于一種假設，即運行時環境將提供內置的垃圾回收、可變對象等功能，而這些功能往往會帶來性能上的損耗。

為了真正提高TypeScript的性能，我們可能需要重新設計其架構，使其更加適應高性能場景：

• 隔離聲明模式：這可能是最直接的方法，通過將類型聲明與實際代碼隔離，可以減少編譯時的計算量，從而提高運行速度。
• 優化全局類型擴展：為了更好地支持并行化，我們需要限制全局類型擴展的使用，以減少潛在的性能瓶頸。
• 改進檢查器運行方式：通過改變TypeScript檢查器的運行方式，可以避免一些不必要的性能損耗，進一步提高運行速度。

然而，任何對TypeScript結構的重大更改都可能導致其API的重大變化，并可能引入新的問題。目前看來，除了可能在2024年推出的隔離聲明模式外，其他的大規模改動短期內不太可能實現。

TypeScript 集成 Linting

另一個策略是將 linting 集成到現有的 TypeScript 語言服務器基礎架構中。TypeScript 語言服務插件允許添加工具作為 TypeScript 編輯體驗的一部分運行。

可以看到過兩次嘗試：

• Quramy/typescript-??-language-service：ESLint 的通用 TypeScript 語言服務插件
• johnsoncodehk/typescript-linter：基于 TypeScript 語言服務器構建的代碼檢查器的重新實現

兩者似乎都有希望。為了與現有規則兼容，在短期內將 ESLint 作為 TypeScript 語言服務插件運行是更可行的。無論哪種方式，在不落后于其他語言的情況下，如何使 TypeScript 體驗變得更好，尤其是考慮到 ESLint 打算擁抱其他 Web 語言，這將是一個關鍵挑戰。

小結

基于 Rust 的 JavaScript/TypeScript 代碼檢查器，如 Biome、deno lint、Oxc 和 RSLint，都是非常快速的項目。但與 ESLint + typescript-ndrings 的類型檢查代碼規則相比，這種速度存在嚴重的功能差距。在決定使用哪個工具時，你應該了解這些權衡。Biome 和 oxlint 都表示在一定程度上建議先運行一個更快的原生速度代碼檢查器，而不是運行基于類型的 typescript-lint。

基于 Rust 的 linter 最終可能會以原生速度代碼獲得類型檢查 linting 的好處。但要實現這一點還有很長的路要走。