Vue language tools: vue-tsc, virtual code and eleven editor clients

vue-tsc type-checks without an editor window

The command line path is two lines of setup, which is the whole reason this package exists separately from the VSCode extension:

npm install vue-tsc typescript --save-dev

Then point a script at it:

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

vue-tsc lives in packages/tsc and is listed as the type-check and dts build command line tool, so the same binary that reports template errors in CI can also build declaration files. The --noEmit flag is what keeps the check read-only. Since it is a plain npm dependency, it drops into any continuous integration runner without an editor, which is the difference between a type error that blocks a merge and one that only shows up when someone opens the file.

@vue/language-core owns SFC parsing and virtual code

One package does the actual work, and it is not the one you install. @vue/language-core is described as SFC parsing and virtual code generation, which is the mechanism the whole project rests on: a .vue file is not valid TypeScript, so the component is decomposed and re-emitted as code that the TypeScript service can type check, with the template expressions mapped back to the original source positions. Three packages sit on top of it. @vue/language-server is the language server itself, @vue/language-service is a collection of language service plugins, and @vue/typescript-plugin is the path that plugs into TypeScript's own language service instead. The repository layout mirrors that split, with packages/, extensions/vscode, lint/, test-workspace/ and changelogs/ at the top level under pnpm workspaces.

Two integration routes, LSP or the TypeScript plugin

Editor support arrives by one of two doors, and picking the wrong one wastes an afternoon. The LSP door is @vue/language-server speaking the Language Server Protocol, which is what community clients such as nvim-lspconfig, LSP-volar for Sublime, coc-volar for coc.nvim and lsp-mode for Emacs attach to. The TypeScript door is @vue/typescript-plugin, a plugin for TypeScript's language service, which is the route for editors that already run the TypeScript service directly. The root README does not state which route a given editor uses, and it does not document message passing or capability negotiation between client and server. WebStorm is named as a different case again: built-in integration for @vue/language-server, meaning the JetBrains side ships support without a separate community client.

Eleven client integrations, eleven other repositories

What the README does give you is the roster of people who built a client for the language server, and the pattern is consistent: this repository ships the server, someone else ships the wiring. coc-volar targets coc.nvim, mattn/vim-lsp-settings configures vim-lsp, kabiaa/atom-ide-volar covers Atom, tommasongr/nova-vue covers Nova, xiaoxin-sky/lapce-vue covers Lapce, and Kingwl/monaco-volar puts Vue language support into Monaco in the browser. Eclipse WildWebDeveloper carries the configuration for Eclipse. Only Neovim gets a link to setup documentation inside this repository, in the project wiki. So the practical cost of using any client other than the official VSCode extension is that you are reading two projects, and the README does not version-lock the client against the server.

Pug templates and component metadata are separate packages

The helper tier covers everything that is not the language server itself. @vue/language-plugin-pug adds Pug template support, which means the core tooling handles HTML templates and Pug arrives as an extra package rather than a configuration flag. vue-component-meta is a tool for extracting component props, events and slots type information, and vue-component-type-helpers supplies component type helper utilities. Read together they describe a division of labour: the server answers questions about the code you are editing, while vue-component-meta is the piece something outside the editor would use to read a component's public surface. What the README does not say is how a project switches the Pug plugin on, or whether vue-component-meta has a command line entry point of its own.

vueCompilerOptions has two documented keys and a pointer

Behaviour is configured inside tsconfig.json rather than in a separate config file, under a vueCompilerOptions key alongside compilerOptions:

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

target sets the Vue version the tooling should assume, and strictTemplates turns on strict checking of template expressions. That is the whole set of options named at the root level. Everything else is deferred: the README sends you to the @vue/language-core documentation for the detailed list, and does not enumerate the remaining keys, their defaults, or the version in which each one appeared. A team standardising on a Vue target has to read the language-core package docs to know what else is available.

pnpm is pinned at 11.9.0 while the toolchain floats

The root package.json is private, declares packageManager as [email protected], and drives the whole monorepo through a handful of scripts:

"build": "tsc -b",
"watch": "tsc -b -w",
"test:grammar": "vitest run extensions/vscode/tests/grammar.spec.ts",
"format": "dprint fmt"

The asymmetry is in the devDependencies. typescript, vitest, dprint and the @tsslint packages are all set to "latest", while the package manager itself is pinned to an exact version and pnpm-lock.yaml plus pnpm-workspace.yaml sit beside it. Contributors work with a floating compiler and formatter, and a matching floating test runner, then open pull requests against that. Building is a project references run with tsc -b, and the lint script spans tsconfig.json, packages/*/tsconfig.json and extensions/*/tsconfig.json in one tsslint invocation.

Release cadence on master, three tags since August

Versions move in small steps on the master branch: v3.3.14 was published on 2026-10-29, v3.3.13 on 2026-10-20, and v3.3.12 on 2026-10-02. The last push landed on 2026-11-01, and the repository is not archived. Licensing is MIT, with a separate changelogs/ directory alongside CHANGELOG.md. For contributors the setup path is explicit, and pnpm is a prerequisite rather than an option:

git clone https://github.com/vuejs/language-tools.git
cd language-tools
pnpm install
npm run build

The README then asks you to use the VSCode Debug Tools launch configs, or the package.json scripts at the repository root, and warns against running anything else. Working against the upstream Volar.js modules instead means setting up the separate volarjs/workspace.

Editorial conclusion

Adopt Vue language tools if you write Vue single file components and want template type errors to fail the build, because vue-tsc --noEmit gives you that without an editor window. Do not adopt it expecting one package to cover every editor: the server lives here, the client configuration for most editors lives in other repositories, and Pug support is a separate install. Verify three things first: that your tsconfig.json sets vueCompilerOptions for your Vue target rather than relying on defaults, that vue-tsc and the TypeScript version you install agree, and whether the editor client you use is the Vue (Official) extension or one of the community integrations listed here.

Frequently asked questions

Official sources

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