发布时间

Volar：新的开始

作者

大多数 Volar 用户都知道它作为官方的 Vue.js VSCode 扩展。它最初是一个个人项目，当时官方推荐的仍然是 Vetur，随着时间的推移，由于架构和性能的改进，它被采用为新的官方扩展。

作为一个旨在提高开发人员生活质量的项目，我们在 达到 1.0 版本 之前花费了两年多的时间，并且一直在不断发布稳定性改进。

但我们还有更多工作要做，并且对 2023 年有令人兴奋的计划。

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

虽然最初是为 Vue 单文件组件的特定需求而设计的，但 Volar 的代码库包含许多不特定于 Vue 的部分，例如

  • 嵌入式编程语言的处理（多个元框架的常见问题）
  • Vue 语言服务器实际上是一个功能齐全的 TypeScript 语言服务器
  • 用于处理与 LSP/Web/嵌入式语言服务交互的代码，等等

我们现在已将这些通用部分提取到一组与框架无关的工具中。这些工具现在作为新的独立项目维护：Volar.js。

Volar.js 的架构旨在支持任何涉及嵌入式语言的文件格式 - 不仅是 Vue，还有 Astro、Svelte，甚至 Angular。它还能够实现常规的单语言 LSP 服务器，例如 TypeScript、CSS 和 HTML。

Volar.js 的另一个主要重点是性能。它旨在最大程度地减少开销，以实现本机嵌入式语言服务的性能。有很多问题和优化机会，只有在拥有庞大的用户群后才能随着时间的推移发现，而 Volar.js 是根据我们从数百万次下载中积累的经验教训进行优化的。

例如，字节跳动旗下的 Lynx 团队是 Volar.js 的早期采用者，他们用一名开发人员两周的时间就发布了一整套支持其内部框架的语言工具。如果从头开始构建，即使是团队也要花费数月的时间才能完成。

旧的 Volar 现在是 vuejs/language-tools ​

随着核心代码的提取，原始 Volar 扩展和 vue-tsc 的代码库已移至 vuejs/language-tools 仓库。此仓库现在依赖于 Volar.js，并包含 Vue 特定支持的代码。

我们还将从 @volar npm 组织中将一些 npm 包移至 @vue - 但这些更改不应影响最终用户。

团队和组织 ​

类似于 Vite 如何从 Vue 生态系统中诞生，并最终发展成为连接整个 Web 开发生态系统用户的社区，Volar.js 希望遵循相同的路径。

我（@johnsoncodehk）与 Erika（@erika）一起组建了 Volar.js 核心团队，Erika 是 Astro 核心团队成员。Erika 与我分享了对改善人们开发体验的愿景和奉献精神。我们将共同努力，为所有 Web 开发人员改善 DX，而不仅仅是 Vue 和 Astro。

我们创建了 volarjs 组织 来维护框架和相关仓库。

此外，我很高兴地宣布

StackBlitz 将全职支持我开发 Volar.js！

我们对未来感到兴奋，并迫不及待地想看看我们未来几个月能取得什么成就！

下一步 ​

我们才刚刚开始，所以还没有明确的长期路线图，但以下是我们计划探索和下一步工作的几个主要方向。

Monaco 支持 ​

Monaco 对 Vue 的支持目前由 monaco-volar 实现，我们计划在框架中支持它，因此所有基于 Volar.js 的语言服务器都将能够轻松地利用它。

支持除 VSCode 之外的 IDE ​

除了 VSCode 之外，许多慷慨的贡献者已经为 Volar 实现了一些其他 IDE 的语言客户端，例如 Vim、Sublime、Atom、Emacs、Nova、Lapce 等。

拥有全面的 IDE 支持具有很大的参考价值，因为很少有人能够精通所有这些 IDE。

我们将寻找方法来利用这些贡献者的努力，以减少框架采用者在 VSCode 之外实现语言客户端的工作量。

此外，虽然 IntelliJ 没有一流的 LSP 支持，但我们将研究是否可以将其与框架集成。

Bun-base 语言服务器 ​

理论上，Volar 的性能只能无限接近，但不能快于原生的 TS 语言服务器。但是，如果 Volar 语言服务器可以通过在 Bun 中运行来获得性能提升，那么这可能是一个游戏规则的改变者。

以前，Bun 的运行时还不兼容基于 Node.js 的 LSP 服务器。我们将密切关注相关问题，并在问题解决后再次尝试。

同样，所有基于 Volar.js 的语言服务器都将能够直接从这一点中受益。

单服务器 ​

想象一下，每种语言都需要支持一些 TypeScript 功能，因此每种语言的语言服务器都会运行自己的昂贵的 TypeScript 语言服务实例，这会让人有点害怕，因为内存和 CPU 使用率都会增加一倍，而这种情况今天已经发生了。

如果其中一些语言服务器基于 Volar.js，我们可能有一些方法让它们决定只激活一个语言服务器，然后将其他语言服务器的功能共享给激活的服务器，这样最终我们只需要在单个语言服务器实例中运行 TypeScript 语言服务，而不是多个语言服务器。

这也可以解决 TypeScript 插件无法支持的一些用例。

基于 Volar.js 的架构，我们已经非常接近这个目标，我和 Erika 将为 Vue 和 Astro 语言服务器探索此功能。

规则 API（内置 Linter） ​

你可能在将 ESLint 和 Prettier 结合使用时遇到过麻烦，我们过去基于插件 API 的尝试并没有很好地避免这个问题。

规则 API 是另一种尝试，旨在避免不同 linting 工具之间的冲突，同时确保性能和功能与 IDE 完美集成。

对于元框架，它们需要为 ESLint 和 Prettier 实现自己的解析器，但使用规则 API，它们甚至不需要这样做，因为我们可以重用 Volar 语言服务器的解析器。

因此，如果你编写了一个 TS 规则，它将通过规则 API 直接在 Vue 的 <script> 和模板的 中的 TypeScript 代码中可用，而无需额外的解析器。

这并不意味着你需要重写所有规则；规则 API 只是一个 API，而不是一个单独的 linter，因此仍然可以重用 ESLint、TSLint 甚至 Rome 中的一些规则。

脚本 API ​

对于 Vue，我们有 vue-tsc 用于检查 TS 代码，有时我们还想在 CI 中同时检查 CSS 和 Vue 模板代码。

脚本 API 旨在公开语言服务器的格式化和 linting 功能，以便它们可以在脚本中使用，允许你在 CI 或 git pre-commit 钩子中使用它，并获得与在 IDE 中相同的结果。

我非常感谢所有当前和过去的赞助商。除了雇用我全职开发 Volar 6 个月之外，Evan You（@youyuxi）继续担任金牌赞助商。 NuxtLabs 也慷慨地延长了他们的白金赞助。没有他们的支持，我们就无法发布 Volar 1.0。

当然，还要感谢 StackBlitz 使我能够全职开发 Volar.js。

如果你想支持 Volar.js 社区的愿景，请不要犹豫 成为赞助商。我希望除了 Volar 之外，你将来也能从 Volar.js 中受益。