Vue-js 官方 IDE-TS 支持工具 Volar：新的開始

2023 年 2 月 8 日，Volar 作者 Johnson Chu 在 Vue.js 官方博客發文展望了 Volar 的 2023 年，下面就來看看詳細內容吧！

Volar 是 Vue.js 官方的 VSCode 擴展。當官方推薦 Vetur 時，Volar 還是一個個人項目，隨着時間的推移，由於改進的性能和體系結構而被採納爲新的官方擴展。作爲一個旨在改善開發體驗的項目，用了兩年多的時間才達到了 1.0 版本，並且一直在不斷改進穩定性。但還有許多工作要做，2023 年有更令人興奮的計劃！

Volar.js：嵌入式語言工具框架

儘管最初是爲 Vue 單文件組件的特定需求而設計的，但 Volar 的代碼庫包含許多不特定於 Vue 的部分，例如：

嵌入式編程語言的處理；
Vue 語言服務器實際上是一個成熟的 TypeScript 語言服務器；
處理與 LSP / Web / 嵌入式語言服務等交互的代碼。

注：語言服務器並不是一個真的服務器，而是把語言相關的特性和功能從 IDE 中解耦出來，作爲一個獨立的程序單獨運行，提供了例如引用查詢等功能的具體實現。

現在已經將這些通用部分提取到一組與框架無關的工具中。這些工具現在作爲一個新的獨立項目進行維護：Volar.js[1]。

Volar.js 的架構支持任何涉及嵌入式語言的文件格式——不僅是 Vue，還包括 Astro、Svelte，甚至 Angular。它還能夠實現常規的單語言 LSP servers，例如 TypeScript、CSS 和 HTML。

Volar.js 的另一個主要關注點是性能。它旨在最大限度地減少實現原生嵌入式語言服務性能的開銷。有很多問題和優化機會，只有在擁有大量用戶的情況下才能發現，而 Volar.js 是根據從數百萬次下載中積累的經驗進行優化的。

例如，字節跳動的 Lynx 團隊是 Volar.js 的早期採用者，一個開發人員用兩週的時間交付了一整套支持其內部框架的語言工具。如果它是從頭開始構建的，即使是一個團隊也需要幾個月的時間。

舊的 Volar 現在是 vuejs/language-tools

提取核心後，原始 Volar 擴展和 vue-tsc 的代碼庫已移至 vuejs/language-tools[2] 存儲庫。這個存儲庫現在依賴於 Volar.js 幷包含對 Vue 特定支持的代碼。

除此之外，還將把一些 npm 包從 @volar 的 npm 組織轉移到 @vue。不過，這些變化不應該影響用戶。

團隊與組織

Vite[3] 從 Vue 生態系統中脫穎而出，並最終成長爲自己的社區，連接整個 Web 開發生態系統的用戶，Volar.js 也希望走同樣的路。

Volar 作者 Johnson Chu 與 Astro 核心團隊成員 Erika 建立了 Volar.js 核心團隊，致力於改善開發者體驗。團隊將共同努力，爲所有 Web 開發者改進 DX，而不僅僅是 Vue 和 Astro。

他們創建了 volarjs 組織來維護框架和相關的存儲庫：

volar.js：框架的核心
plugins[4]: 可以在 volar.config.js 或框架的 plugins 中使用
volarjs.github.io[5]：官方網站
language-tools-starter[6]：開始使用 Volar.js 構建語言服務器模板
ecosystem-ci[7]：用於運行 volar 生態系統項目的集成測試
pug-language-tools[8]：基於 language-tools-starter 的 Pug 工具
angular-language-tools[9]：基於 language-tools-starter 的 Angular 示例
svelte-language-tools[10]：基於 language-tools-starter 的 Svelte 示例

下一步

這只是一個開始，目前還沒有明確的長期路線圖，但這裏有一些計劃在接下來探索和努力的主要方向。

Monaco 支持

Monaco 對 Vue 的支持目前由 monaco-volar 實現，Volar 團隊計劃在框架中支持它，因此所有基於 Volar.js 的語言服務器都可以輕鬆使用它。

支持 VSCode 以外的 IDE

除了 VSCode 之外，許多貢獻者還爲 Volar 的 Vim、Sublime、Atom、Emacs、Nova、Lapce 等其他 IDE 實現了語言客戶端。擁有一整套的 IDE 支持可能有很大的參考價值，因爲很少有人能夠精通所有這些 IDE。

Volar 團隊將尋找方法來利用這些貢獻者的努力，以減少框架使用者在 VSCode 之外實現語言客戶端的工作量。

除此之外，雖然 IntelliJ 沒有一流的 LSP 支持，Volar 團隊將研究是否可以將其與框架集成。

基於 Bun 的語言服務器

理論上，Volar 的性能只能無限接近，但不會快於 vanilla TS 語言服務器。但是，如果 Volar 語言服務器可以通過在 Bun 中運行而獲得性能提升，它可能會改變遊戲規則。

以前 Bun 運行時還不兼容基於 Node.js 的 LSP 服務器。Volar 團隊會持續關注相關問題，待問題解決後進行重試。同樣，所有基於 Volar.js 的語言服務器都將能夠直接從中受益。

單體服務器

想象一個場景，每種語言都需要支持一些 TypeScript 特性，那麼每種語言的語言服務器都會運行自己昂貴的 TypeScript 語言服務實例，這讓情況變得變得糟糕，因爲內存和 CPU 使用率都會成倍增加，而這種情況如今已經發生了。

如果這些語言服務器中的一些是基於 Volar.js 的，可能有一些方法讓他們決定只激活一個語言服務器，然後將其餘語言服務器的功能共享給激活的服務器，這樣最終只需要在一個語言服務器實例而不是多個語言服務器中運行 TypeScript 語言服務。

這也可以解決 TypeScript 插件無法支持的一些用例。

基於 Volar.js 架構，已經非常接近這個目標，Volar 團隊將爲 Vue 和 Astro 語言服務器探索這個特性。

Rules API（內置 Linter）

在 ESLint 和 Prettier 一起使用時可能會出現衝突，而過去基於 Plugin API 的嘗試並沒有很好地避免這個問題。

Rules API 是避免不同 linting 工具之間衝突的另一種嘗試，同時也確保性能和特性與 IDE 完美集成。

對於元框架，它們需要爲 ESLint 和 Prettier 實現自己的解析器，但是有了 Rules API，它們甚至不需要這樣做，因爲可以重用 Volar 語言服務器的解析器。

因此，如果編寫了一個 TS 規則，它將直接通過 Rules API 用於 Vue 的 <script> 和模板中的 TypeScript 代碼，而不需要額外的解析器。

這並不意味着需要重寫所有規則；Rules API 只是一個 API，而不是一個單獨的 linter，因此仍然可以重用 ESLint、TSLint 甚至 Rome 中的一些規則。

Scripts API

對於 Vue，有 Vue-tsc 來檢查 TS 代碼，Volar 團隊也想在 CI 中同時檢查 CSS 和 Vue Template 代碼。

Scripts API 旨在公開語言服務器的格式化和 linting 功能，以便它們可以在腳本中使用，允許開發者在 CI 或 git 預提交 Hooks 中使用它並獲得與在 IDE 中相同的結果。

原文：https://blog.vuejs.org/posts/volar-a-new-beginning.html