自動化在DevOps中的力量：簡化軟件開發和交付
自動化在DevOps中扮演著重要角色，它提升了DevOps的效能。通過自動化工具和方法，DevOps團隊可以實現以下目標：消除手動和重復性任務。簡化流程。在整個軟件開發生命周期中實現更
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 功能缺失。
傳統上，像 ESLint 這樣的 lint 工具一次只能檢查一個源代碼文件。這使得它們運行速度較快，理論上可以進行緩存和并行處理。
typescript-eslint 引入了使用類型信息的 linting 概念。通過調用 TypeScript 的類型檢查 API，lint 規則可以根據項目中的其他文件提供的類型信息，對代碼做出更加明智的決策。
類型檢查的 lint 規則可能比傳統的 lint 規則功能更強大。例如：
這些規則只有在能夠使用類型信息來確定何時報告問題時才有實際用處。沒有類型信息，它們將無法理解從另一個模塊導入的值的類型。
類型檢查的 linting 相比傳統 linting 存在的主要劣勢在于性能。這是因為類型化的 lint 規則需要調用 TypeScript 等 API 來獲取類型信息，通常需要讀取所有文件以確定哪些文件會影響其他文件的類型。因此，類型檢查的 linting 性能通常會低于對整個項目運行 TypeScript 的性能。
TypeScript 本身也在不斷優化性能。例如，項目引用可以顯著幫助處理更大的項目。TypeScript 即將推出的獨立聲明模式看起來也可以顯著提高處理更大項目的性能。
但即使所有這些加速都完美地工作，類型檢查的 linting 設計上仍然比傳統的 linting 慢幾個數量級。因為從項目中推斷類型的過程本質上比傳統的 lint 規則一次只查看一個文件要慢得多。
大多數情況下，當看到類型檢查的速度慢的項目時，根本原因要么是 typescript-eslint 配置錯誤，要么是 TypeScript 類型慢。
目前還沒有基于 Rust 的代碼檢查器與 TypeScript 的類型檢查 API 集成，這意味著基于 Rust 的代碼檢查器不能完全替代 ESLint + typescript-lint。
如果你不需要任何類型檢查的 lint 規則，那么可以切換到基于 Rust 的 linter。但強烈建議你至少查看 typescript-lint 中推薦的類型檢查規則，以了解缺少什么。
甚至可以同時運行這兩種工具：首先使用原生速度的 linter 快速反饋，然后僅使用 typescript-eslint 查看包含類型信息的規則。這個想法得到了多個原生速度 linter 維護者的支持：
這種互補而非取代的愿望部分源于這兩種 lint 工具在運作方式上的重大結構性差異。原生速度的 lint 工具尚未在其 lint 規則中實現類型檢查。下面來深入探討這一奇怪的功能差距。
目前，TypeScript 的核心功能是為 TypeScript 編譯器和語言服務提供支持的代碼，它是唯一能夠為 TypeScript 代碼提供可靠類型檢查的組件。由于TypeScript是用TypeScript編寫的，因此其類型檢查以JavaScript的速度運行。
為了實現與 TypeScript 的類型檢查的集成，基于Rust的代碼檢查器面臨幾個選擇：
此外，基于 Rust 的 linter 不允許在 JavaScript 中編寫自定義 lint 規則。雖然這對大多數 JavaScript 生態系統來說是一個貢獻障礙，但這與本文的重點是兩個獨立的問題。
因此，將基于 Rust 的代碼檢查器與 TypeScript 的類型檢查集成在一起有不同的選項。
選擇這種性能影響方案可能會使基于 Rust 的 linter 速度降低到幾乎與 ESLint 無明顯性能優勢的程度。
對于 TypeScript 用戶來說，以原生速度重新實現 TypeScript 是一個極具吸引力的前景，而不僅僅是對于 linter。目前已有三個重要的嘗試：
需要注意的是，以新語言重新實現 TypeScript 是一項艱巨的任務。TypeScript 的類型推理需要處理泛型類型、協變、逆變等復雜邊緣情況，這是一項極具挑戰性的任務。這些項目目前都處于非常早期的階段，可能需要很長時間才能準備投產。
那是否可以通過縮小項目的范圍，只實現TypeScript的類型推理部分，從而降低這一選項的復雜性呢？對于 linters 來說，一個簡化版的TypeScript，跳過源代碼轉換、類型檢查可分配性錯誤等部分，只專注于編程類型檢查API，或許更為實用。例如，Oxc 項目已經成功地實現了一個 TypeScript 類型推理的簡化版，僅用幾千行Rust代碼就完成了這一任務。
然而，我們必須正視TypeScript背后有一個強大的開發團隊和社區支持的現實。TypeScript團隊由專業的編程語言專家組成，并且持續從社區中獲得貢獻。對于任何嘗試重新實現TypeScript的項目來說，跟上TypeScript的更新步伐是一項幾乎不可能完成的任務。盡管Ezno和stc等項目展現了令人印象深刻的成果，但它們作為獨立項目的長期可行性仍然充滿了不確定性。
為了提高TypeScript的性能，一個更具可行性的長期方案是優化其類型檢查器的運行速度。目前有幾種可能的解決方案：
這些方案都面臨一定的挑戰，需要投入時間和資源進行開發。然而，通過持續優化和改進，可以逐步提高TypeScript的性能，使其更加適應快速發展的開發需求。
雖然可以通過各種方法來加速TypeScript的運行，但其實TypeScript本身的架構是阻礙性能提升的主要因素。它的代碼基于一種假設，即運行時環境將提供內置的垃圾回收、可變對象等功能，而這些功能往往會帶來性能上的損耗。
為了真正提高TypeScript的性能，我們可能需要重新設計其架構，使其更加適應高性能場景：
然而，任何對TypeScript結構的重大更改都可能導致其API的重大變化，并可能引入新的問題。目前看來，除了可能在2024年推出的隔離聲明模式外，其他的大規模改動短期內不太可能實現。
另一個策略是將 linting 集成到現有的 TypeScript 語言服務器基礎架構中。TypeScript 語言服務插件允許添加工具作為 TypeScript 編輯體驗的一部分運行。
可以看到過兩次嘗試：
本文鏈接：http://www.www897cc.com/showinfo-26-61902-0.html基于 Rust 的 linter 工具速度很快，但有嚴重缺陷...
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 良心推薦！幾款收藏的神級IDEA插件分享
下一篇： Go 內存優化與垃圾收集
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號