vuejs/language-tools: Vue SFC type checking and editor support

What vuejs/language-tools actually covers

The repository is not a single tool. It is a set of packages that split along audience lines, and the README makes that split explicit. For end users there are two entries: the Vue (Official) extension for VS Code, described as language support for Vue, Vitepress and petite-vue, and vue-tsc, a command line tool for type checking and dts builds. Everything else in the package table exists for editor integrators or for people building on top of the core.

The second group is the integration surface: @vue/language-server, @vue/language-service and @vue/typescript-plugin. The third is @vue/language-core, which the README describes as SFC parsing and virtual code generation. Helper tools round it out: vue-component-meta for extracting props, events and slot types, vue-component-type-helpers, and @vue/language-plugin-pug for Pug template support.

That structure tells you who the project is for. If you write Vue components and use an editor with an LSP client, you are the end user. If you maintain an editor plugin or a build tool that needs to understand .vue files, you consume the language server or the core module. The README does not try to serve both audiences with one set of instructions, and that is the right call.

How the virtual code layer works

The mechanism the README points at is virtual code generation in @vue/language-core. A .vue file is not valid TypeScript, so the language server cannot hand it to tsserver directly. The core module parses the single-file component and produces virtual documents that TypeScript can consume, which is what makes template expressions type-checkable at all.

The README links Volar.js as the foundation and describes the toolset as having native TypeScript performance based on it. The architecture diagram is hosted externally as an SVG rather than embedded as text, so the README itself does not walk through the data flow step by step. What is visible from the repository layout is the layering: extensions/ holds the VS Code client, packages/language-server holds the server, packages/language-service holds a collection of service plugins, and packages/language-core holds the parsing and virtual code work.

The practical consequence is that the same core serves every editor. WebStorm is listed as having built-in integration for @vue/language-server, and the community section lists clients for coc.nvim, nvim-lspconfig, vim-lsp-settings, Sublime, Atom, Emacs lsp-mode, Nova, Lapce and Monaco. One server, many clients. That is a deliberate trade: the server has to stay editor-neutral, so anything editor-specific lives in the client, which is why the VS Code extension has its own directory and its own build script.

Installing vue-tsc for command-line type checking

The README's quick start gives two paths. For VS Code users it is an extension install from the marketplace under the name Vue (Official). For type checking from a terminal, the documented step is installing vue-tsc and typescript as dev dependencies, then wiring a script.

npm install vue-tsc typescript --save-dev

The README then shows the script entry to add to package.json, with vue-tsc --noEmit as the command. Running that script type-checks the project without emitting output files, which is the shape you want in CI.

{
  "scripts": {
    "type-check": "vue-tsc --noEmit"
  }
}

Compiler behaviour is configured through a vueCompilerOptions block inside tsconfig.json, alongside the normal compilerOptions. The README's example sets target to 3.5 and strictTemplates to true. The target value needs to match the Vue version you are actually running, and the README defers detailed option documentation to the @vue/language-core package rather than listing them all in the root file.

{
  "compilerOptions": { /* ... */ },
  "vueCompilerOptions": {
    "target": 3.5,
    "strictTemplates": true
  }
}

If you are contributing to the extension itself rather than using it, the README requires pnpm and gives a clone, install and build sequence, with a warning to use the debug launch configs or root package.json scripts rather than invoking things from subdirectories.

Where the tooling stops short

Pug is the clearest boundary. Template support for Pug is not in the core package; it lives in @vue/language-plugin-pug, listed separately under helper tools. If your components use Pug templates and you install only the extension or vue-tsc, the README gives no indication that template checking will work. You have to know the plugin exists and add it.

The second gap is documentation depth in the root README. vueCompilerOptions is introduced with two keys and a pointer to another package's documentation. There is no table of options, no deprecation notes, and no migration guidance between major versions in the root file. The repository does carry a CHANGELOG.md and a changelogs/ directory, so version history exists, but the README does not summarise it. Anyone upgrading across a major version should read those files rather than assume compatibility.

The third is rollback. The README does not document how to revert an extension version or pin the language server to an older release. If a new release breaks your editor session, the documented material gives you nothing to follow, and you are left with the standard extension management UI in your editor.

Finally, the project is editor-agnostic by design, which means setup instructions for anything other than VS Code live outside the README. Neovim users are pointed at a wiki page. The community section lists clients for many editors but does not describe their configuration.

How it differs from running plain tsc on Vue projects

The obvious alternative is TypeScript's own tsc, and the difference is structural rather than a matter of speed. tsc has no concept of a .vue file. It sees a file type it does not parse, so template expressions, props passed in templates and slot types are invisible to it. You get type checking for the script block only if you have arranged for something else to extract it, and nothing checks the template at all.

vue-tsc exists precisely to close that gap, and the README frames it as a type-check and dts build command line tool sitting alongside the extension. The virtual code layer in @vue/language-core is what feeds tsc-compatible input, which is why the same project can offer both editor diagnostics and a CI gate from one codebase.

A second alternative is to rely on the editor extension alone and skip the command line step. That works until CI. Editor diagnostics do not fail a build, and the README's quick start presents the two paths as complementary rather than interchangeable: the extension for interactive feedback, vue-tsc for the check you can automate. Teams that only install the extension are checking types manually, one file at a time, in whatever editor each developer happens to use.

For editors outside VS Code, the alternative is a different client for the same server. WebStorm bundles integration for @vue/language-server, and Neovim, Emacs, Sublime and others have community clients. The server is the constant; the client is the variable.

Maintenance cost and licence position

The last push to the default branch was on 2026-09-21, one day before this article's reference point, and the repository is not archived. Releases have been frequent: v3.3.9 on 2026-07-31, v3.3.10 on 2026-08-15, v3.3.11 on 2026-08-21. That cadence means the upgrade surface is real. Each release can change language server behaviour, and the README does not document a rollback path, so pinning matters more than usual for editor integrations.

For contributors the cost is higher than for users. The README requires pnpm, and package.json pins packageManager to [email protected]. The build is tsc -b across the workspace, tests run through vitest after a build, lint runs through tsslint across three tsconfig globs, and formatting is dprint. The README warns to use the debug launch configs or root package.json scripts rather than scripts in subdirectories, which suggests the workspace has cross-package build ordering that a naive per-package invocation would break.

Licensing is MIT, per the LICENSE file and the badge in the README. That is permissive and imposes no copyleft obligation on your own code. It says nothing about the marketplace listing or the extension's distribution terms, and nothing here should be read as legal advice; if you redistribute the extension or bundle the language server into a product, read the LICENSE file itself.

Editorial conclusion

Adopt it if you write Vue single-file components and want type checking to run against templates as well as script blocks, since vue-tsc --noEmit is the documented path and the VS Code extension is a single install. Skip it if you need Pug templates without adding @vue/language-plugin-pug, or if you expect the README to document a rollback or migration procedure, because it does not. Before committing, verify that your tsconfig.json carries a vueCompilerOptions block with the target matching your Vue version, and confirm your editor client is listed in the community integration section rather than assumed.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vuejs/language-tools on GitHub