大多数 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存储库。这个 repo 现在依赖于 Volar.js 并包含 Vue 特定支持的代码。
我们还将把一些 npm 包从@volar npm 组织移到@vue- 但这些更改不应该影响最终用户。
团队与组织
类似于 Vite 诞生于 Vue 生态系统，并最终发展成自己的社区，连接整个 Web 开发生态系统的用户，Volar.js 希望遵循同样的道路。
我 ( @johnsoncodehk ) 已经与Astro 核心团队成员Erika ( @erika )建立了 Volar.js 核心团队。Erika 与我一样，致力于改善人们的开发体验。我们将共同努力，为所有网络开发者改进 DX，而不仅仅是 Vue 和 Astro。
我们已经创建了 volarjs 组织来维护框架和相关的回购协议。
- volar.js : 框架的核心
- plugins : 可以在
volar.config.js框架中或插件中使用 - volarjs.github.io : 官方网站
- language-tools-starter：开始使用 Volar.js 构建语言服务器的模板
- ecosystem-ci：用于运行 volar 生态系统项目的集成测试
- pug-language-tools : 基于 language-tools-starter 的 Pug 工具
- angular-language-tools：基于 language-tools-starter 的 Angular 示例
- svelte-language-tools：基于 language-tools-starter 的 Svelte 示例
此外，我很高兴地宣布：
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 基础语言服务器
理论上，Volar 的性能只能无限接近，但不会快于 vanilla TS 语言服务器。但是，如果 Volar 语言服务器可以通过在 Bun 中运行来获得性能提升，它可能会改变游戏规则。
以前 Bun 的运行时还不兼容基于 Node.js 的 LSP 服务器。我们会持续关注相关问题，待问题解决后重试。
同样，所有基于 Volar.js 的语言服务器都将能够直接从中受益。
单体服务器
想象这样一个场景，每一种语言都需要支持一些 TypeScript 特性，那么每一种语言的语言服务器都会运行自己昂贵的 TypeScript Language Service 实例，这让事情变得有点可怕，因为内存和 CPU 使用率都会成倍增加，而这种情况今天已经发生了。
如果这些语言服务器中的一些是基于 Volar.js 的，我们可能有一些方法让他们决定只激活一个语言服务器，然后将其余语言服务器的功能共享给激活的服务器，这样在最终我们只需要在一个语言服务器实例而不是多个语言服务器中运行 TypeScript 语言服务。
这也可以解决 TypeScript 插件无法支持的一些用例。
基于 Volar.js 架构，我们已经非常接近这个目标，我和 Erika 将为 Vue 和 Astro 语言服务器探索这个特性。
规则 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 中的一些规则。
脚本API
对于 Vue 我们有vue-tsc检查 TS 代码，有时我们也想在 CI 中同时检查 CSS 和 Vue Template 代码。
Scripts API 旨在公开语言服务器的格式化和 linting 功能，以便它们可以在脚本中使用，允许您在 CI 或 git 预提交钩子中使用它并获得与在 IDE 中相同的结果。
