Vue.js 官方 IDE/TS 支持工具 Volar：新的开始

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 中相同的结果。