Volar vs. Vue Language Server: IDE-Tooling für Vue 3 im Vergleich

1. Volar und Vue Language Server: zwei Namen, ein System

Volar war ursprünglich der Name eines einzelnen VS-Code-Extension-Projekts von Johnson Chu, das Vue-3-Entwicklern erstmals vollständige TypeScript-Unterstützung direkt in Single File Components brachte.

Mit wachsender Reife wurde das zugrundeliegende Sprachserver-Backend als eigenständiges Paket unter dem Namen Vue Language Server, technisch @vue/language-server, ausgelagert, während Volar zur reinen VS-Code-Erweiterung wurde, die diesen Server im Hintergrund startet und mit dem Editor verbindet.

Diese Trennung ist für die Praxis entscheidend: Wer VS Code nutzt, installiert die Extension namens Volar aus dem Marketplace, ohne sich um den darunterliegenden Server kümmern zu müssen.

Wer hingegen einen anderen Editor nutzt, etwa Neovim, Zed oder PhpStorm, installiert dort keine Volar-Extension, sondern eine editor-spezifische Integration des Vue Language Server über das Language Server Protocol, kurz LSP, ein von Microsoft entwickeltes, editor-unabhängiges Protokoll für Sprachdienste.

Der Vue Language Server selbst ist damit der eigentliche Kern der gesamten Vue-IDE-Erfahrung, unabhängig vom verwendeten Editor.

Volar bleibt der geläufigste Name in Diskussionen und Dokumentationen, gemeint ist damit aber meistens die Kombination aus VS-Code-Extension und Vue Language Server als technisches Gesamtsystem, nicht die Extension allein.

Das gesamte Projekt firmiert inzwischen unter dem Namen Vue Language Tools, wobei Volar als Markenname für die VS-Code-Variante erhalten bleibt.

Für Entwickler, die aus dem Vue-2-Zeitalter kommen, ist zusätzlich relevant, dass der Vorgänger von Volar, die Extension Vetur, ein komplett anderes technisches Fundament nutzte und keine vergleichbare TypeScript-Integration bot.

Der Umstieg von Vetur auf Volar war deshalb nicht nur ein Versions-Update, sondern ein grundlegender Architekturwechsel, der mit der Einführung von Vue 3 und script setup einherging.

2. Architektur: wie der Vue Language Server TypeScript versteht

Der zentrale technische Beitrag des Vue Language Server ist eine Technik, die intern als Virtual Code bezeichnet wird.

Eine .vue-Datei ist für den TypeScript-Compiler von Haus aus unlesbar, da TypeScript nur .ts- und .tsx-Dateien versteht.

Der Vue Language Server erzeugt deshalb im Hintergrund eine virtuelle TypeScript-Repräsentation jeder Vue-Datei, in der Template-Ausdrücke, Props-Typen und der Script-Block zu validem TypeScript-Code transformiert werden, ohne dass diese Datei tatsächlich auf der Festplatte existiert.

Diese virtuelle Datei wird dann an denselben TypeScript-Sprachserver weitergereicht, der auch reine .ts-Dateien analysiert, wodurch Autovervollständigung, Gehe-zu-Definition und Typüberprüfung im Template dieselbe Qualität erreichen wie in normalem TypeScript-Code.

Genau diese Virtual-Code-Architektur ist der Grund, warum der Vue Language Server als generisches Framework namens @volar/language-server entstanden ist, das mittlerweile auch für andere Template-Sprachen wie Astro oder MDX wiederverwendet wird.

Ein Nebeneffekt dieser Architektur: Fehlermeldungen, die im Editor erscheinen, beziehen sich intern auf Zeilen der virtuellen TypeScript-Datei, werden aber vom Vue Language Server für die Anzeige zurück auf die passende Zeile in der echten .vue-Datei abgebildet.

Bei komplexen Template-Ausdrücken kann diese Rückabbildung gelegentlich ungenau sein, ein Grund, warum manche Fehlermeldungen in Templates eine Zeile zu früh oder zu spät markiert erscheinen.

Interessant ist außerdem, dass dieselbe Virtual-Code-Engine parallel mehrere Sprachdienste bedienen kann: Neben der reinen TypeScript-Analyse laufen darüber auch CSS-Sprachdienste für den style-Block und, sofern konfiguriert, Linting-Regeln für den Template-Bereich.

Diese Mehrfachnutzung derselben zugrundeliegenden Infrastruktur ist einer der Gründe, warum sich das Vue-Language-Server-Team dafür entschieden hat, die Kernkomponente als generisches, wiederverwendbares Framework zu veröffentlichen, statt sie fest an Vue zu koppeln.

3. Der historische Take-Over-Modus und seine Ablösung

Frühere Volar-Versionen kannten den sogenannten Take-Over-Modus.

Da VS Code für .ts-Dateien standardmäßig den eingebauten TypeScript-Sprachserver von Microsoft nutzt, musste Volar in diesem Modus den eingebauten Server für reine TypeScript-Dateien im Projekt komplett deaktivieren und durch die eigene, Vue-fähige Variante ersetzen, damit projektweite Funktionen wie Umbenennen über Datei-Grenzen hinweg zwischen .vue- und .ts-Dateien konsistent funktionierten.

Dieser Take-Over-Modus war fehleranfällig, weil er zwei konkurrierende TypeScript-Instanzen im selben Editor-Prozess erforderte und bei falscher Konfiguration zu doppelten oder widersprüchlichen Fehlermeldungen führte.

Seit Vue Language Tools Version 2 wurde diese Notwendigkeit durch eine tiefere Integration mit dem TypeScript-Plugin-System behoben: Ein @vue/typescript-plugin registriert sich direkt beim regulären TypeScript-Sprachserver, sodass kein separater Take-Over-Modus mehr nötig ist und der native TypeScript-Server von VS Code unverändert weiterläuft.

// tsconfig.json — enabling the Vue TypeScript plugin explicitly
{
  "compilerOptions": {
    "plugins": [
      { "name": "@vue/typescript-plugin" }
    ]
  },
  "include": ["src/**/*.ts", "src/**/*.vue"]
}

// This registers Vue support directly inside the regular
// TypeScript language server, no separate take-over mode needed.

4. Volar in VS Code: Installation und Konfiguration

Für VS Code reicht die Installation der Extension Vue.volar aus dem Marketplace.

Wichtig ist, vorher sicherzustellen, dass keine ältere Vetur-Extension parallel aktiv ist, da Vetur das ältere, für Vue 2 konzipierte Sprachserver-Tooling ist und mit Volar in Konflikt gerät, wenn beide gleichzeitig auf dieselben Dateitypen reagieren.

Volar erkennt Vue-3-Projekte automatisch über die installierte Vue-Version in package.json und aktiviert passende Funktionen wie Template-Typüberprüfung entsprechend.

Für Projekte mit strengem TypeScript lohnt sich die zusätzliche Einstellung vue.server.hybridMode, die standardmäßig aktiviert ist und für die beschriebene Plugin-Integration statt des alten Take-Over-Modus sorgt.

Wer stattdessen bewusst den klassischen, eigenständigen Modus benötigt, etwa für sehr spezielle Monorepo-Setups, kann diesen über die Einstellungen explizit reaktivieren, sollte sich aber der genannten Nachteile bewusst sein.

5. Vue Language Server in PhpStorm, Neovim und Zed

PhpStorm und die anderen JetBrains-IDEs bringen mit dem Vue.js-Plugin eine eigene, native Implementierung mit, die teilweise auf denselben Grundideen wie der Vue Language Server aufbaut, aber als eigenständiges JetBrains-Plugin gepflegt wird, nicht als direkter LSP-Client für @vue/language-server.

Für viele Projekte reicht das aus, bei sehr neuen Vue-Features kann es aber vorkommen, dass das JetBrains-Plugin aktuelle Compiler-Makros oder Syntax-Erweiterungen etwas später unterstützt als Volar in VS Code.

Für Neovim gibt es mit nvim-lspconfig eine direkte, offiziell unterstützte Konfiguration für den Vue Language Server über das Standard-LSP-Protokoll, ergänzt um das @vue/typescript-plugin für dieselbe Hybrid-Mode-Integration wie in VS Code.

Editoren wie Zed, die nativ auf LSP setzen, binden den Vue Language Server ebenfalls direkt über dessen Standard-Protokoll ein, wodurch dieselbe Kernfunktionalität, wenn auch mit teils abweichender Konfigurationssyntax, in nahezu jedem modernen Editor verfügbar ist.

# Neovim: installing the Vue Language Server via a package manager
# and wiring it up through nvim-lspconfig

# Mason-managed install of the language server binary
:MasonInstall vue-language-server

# Minimal lspconfig setup (Lua), hybrid mode via the TS plugin
require('lspconfig').volar.setup({
  filetypes = { 'vue' },
  init_options = {
    vue = { hybridMode = true },
  },
})

6. Typüberprüfung in Templates: was funktioniert und was nicht

Der Vue Language Server prüft Template-Ausdrücke mit derselben Strenge wie Script-Code, sofern strict in der tsconfig.json aktiviert ist.

Ein Tippfehler in einem Property-Namen innerhalb eines v-if-Ausdrucks wird ebenso als Fehler markiert wie ein falscher Typ, der an eine Kindkomponente übergeben wird, inklusive korrekter Typinferenz für v-for-Schleifenvariablen und für per defineSlots typisierte Slot-Props.

Grenzen bestehen bei sehr dynamischen Konstrukten, etwa wenn Komponenten zur Laufzeit über eine Variable statt eines statischen Tag-Namens aufgerufen werden, oder bei global registrierten Komponenten und Direktiven, die außerhalb des aktuellen Dateikontexts definiert sind.

Für global registrierte Komponenten hilft eine manuelle Typdeklaration in einer .d.ts-Datei, damit der Vue Language Server auch außerhalb lokaler Imports korrekte Typinformationen bereitstellen kann.

Ein weiterer praxisrelevanter Fall betrifft v-model in Kombination mit defineModel: Der Vue Language Server prüft den Typ des gebundenen Werts auf beiden Seiten der Bindung, also sowohl in der Kindkomponente als auch im Elternteil, und meldet eine Typabweichung sofort im Editor, bevor der Code überhaupt kompiliert wird.

Diese Art von End-zu-End-Typprüfung über Komponentengrenzen hinweg ist einer der größten praktischen Vorteile gegenüber der Situation vor Einführung des Vue Language Server, als Props-Typen zwischen Komponenten oft nur implizit über Dokumentation kommuniziert wurden.

7. Performance bei großen Vue-Projekten

Die Virtual-Code-Architektur des Vue Language Server hat einen Preis: Jede geöffnete oder importierte .vue-Datei erzeugt intern eine zusätzliche virtuelle TypeScript-Datei, die vom TypeScript-Compiler mit analysiert werden muss.

Bei sehr großen Vue-Projekten mit mehreren tausend Komponenten kann das zu spürbaren Verzögerungen bei Autovervollständigung und projektweiter Fehlerprüfung führen, insbesondere direkt nach dem Öffnen des Projekts, wenn der initiale Typ-Cache noch aufgebaut wird.

Der Hybrid-Modus reduziert diese Last gegenüber dem alten Take-Over-Modus spürbar, da nur noch ein einziger TypeScript-Prozess statt zwei parallele Instanzen läuft.

Für sehr große Monorepos empfiehlt sich zusätzlich, projektweite Typüberprüfung über vue-tsc in die CI-Pipeline auszulagern, statt sie ausschließlich im Editor laufen zu lassen, sodass der Vue Language Server im Editor primär für schnelles, lokales Feedback zuständig bleibt.

8. Typische Fehlerdiagnose und Troubleshooting

Der häufigste Fehler in der Praxis ist eine parallel installierte Vetur-Extension, die mit Volar um dieselben Dateitypen konkurriert und zu doppelten, widersprüchlichen Fehlermeldungen führt.

Die Lösung ist immer, Vetur vollständig zu deaktivieren oder zu deinstallieren, sobald ein Projekt auf Vue 3 migriert ist, da Vetur ausschließlich für Vue 2 konzipiert wurde und keine script setup-Unterstützung bietet.

Ein zweiter häufiger Fall sind veraltete Typinformationen nach größeren Refactorings, meist gelöst durch einen Neustart des TypeScript-Servers über die Kommandopalette, ohne dass der gesamte Editor neu gestartet werden muss. Ein dritter, subtilerer Fall betrifft Monorepos mit mehreren tsconfig.json-Dateien, bei denen der Vue Language Server die falsche Konfiguration für ein Paket auflöst, meist gelöst durch explizite references-Einträge in der Root-tsconfig.json, die dem Server die korrekte Projektstruktur mitteilen.

Ein vierter, oft übersehener Fall betrifft veraltete, global installierte Versionen des Vue Language Server, die mit der lokal im Projekt über package.json gepinnten Version in Konflikt geraten. Volar nutzt standardmäßig die im Projekt installierte Version, sofern vorhanden, weicht aber bei fehlender lokaler Installation auf eine gebündelte Fallback-Version aus, was zu inkonsistentem Verhalten zwischen verschiedenen Rechnern im selben Team führen kann, wenn nicht alle dieselbe Version explizit als Dev-Dependency führen.

9. Editoren und ihre Vue-Language-Server-Integration im Vergleich

Die folgende Tabelle vergleicht die wichtigsten Editoren hinsichtlich ihrer Integration des Vue Language Server beziehungsweise einer äquivalenten, nativen Implementierung.

Für die meisten Teams ist VS Code mit Volar der Referenzweg mit dem geringsten Reibungsverlust, da neue Vue-Features hier zuerst ankommen. Wer aus organisatorischen Gründen an PhpStorm oder einen anderen Editor gebunden ist, sollte gezielt prüfen, ob aktuell benötigte Vue-Features, etwa neue Compiler-Makros, bereits vollständig unterstützt werden, bevor größere Refactorings darauf aufgebaut werden.

10. Zusammenfassung

Volar ist der Name der VS-Code-Extension, der Vue Language Server das eigentliche, editor-unabhängige Backend, das über Virtual Code TypeScript-Analyse in Single File Components ermöglicht. Der frühere Take-Over-Modus wurde durch eine direkte Plugin-Integration mit dem regulären TypeScript-Sprachserver abgelöst, wodurch Konflikte mit dem nativen VS-Code-TypeScript-Support entfallen.

Für VS Code ist die Installation der Volar-Extension der unkomplizierteste Weg, für PhpStorm existiert ein natives, eigenständiges Plugin, und für Neovim, Zed und andere LSP-fähige Editoren lässt sich der Vue Language Server direkt über das Standard-Protokoll einbinden. Wichtig bleibt in jedem Fall, veraltete Erweiterungen wie Vetur zu entfernen und bei großen Projekten Typüberprüfung zusätzlich über vue-tsc in der CI-Pipeline abzusichern.

11. FAQ: Volar vs. Vue Language Server