Vite 8.1.0 stable, veröffentlicht am 2026-06-23 von github-actions aus dem v8.1.0-Tag (Commit 63b1489, release: v8.1.0), ist das erste Feature-Release auf dem stabilen Vite-8-Branch seit der 8.1-Beta vom 2026-06-15. Das Release liefert dieselbe Code-Linie wie die Beta, plus einen neuen dokumentierten experimentellen Einstiegspunkt (Bundled Dev Mode), drei Wochen an Bug-Fix-Patches (das Beta-CHANGELOG listet 22 Commits zwischen v8.1.0-beta.0 und v8.1.0), eine verschärfte Default-server.fs.deny-Liste, eine Tilde-gepinnte Rolldown-Abhängigkeit, die es dem Bundler erlaubt, Patch-Releases ohne Vite-PR zu veröffentlichen, und eine Runtime-Deprecation-Warnung für envFile: false. Am selben Tag erscheint Rolldown 1.1.3 mit zehn Folgefixes, darunter ein Crash auf dem Browser-Main-Thread und ein Close-Reentrancy-Fix im Watch-Mode.
Das Release erscheint acht Tage nach der Beta, schneller als die Kadenz von Vite 7 zu Vite 8. Der Announcement-Post des Vite-Teams merkt an, dass Vite nun 41,6 Millionen wöchentliche Downloads auf npm erreicht, „fast die Gesamtzahl der Downloads von Vite 7". Bundled Dev Mode ist das Feature, das den Minor-Line-Bump allein rechtfertigt: 15x Verbesserung beim Cold Start einer React-App mit 10 000 Komponenten und Linear in der Praxis bei 3x schnellerem Cold Start und 10x weniger Netzwerk-Requests.
Bundled Dev Mode, das Top-Feature
Der größte einzelne Zusatz in 8.1.0 stable ist Bundled Dev Mode, der nicht mehr ein Flag ohne Doku ist. Es gibt jetzt einen dedizierten CLI-Einstiegspunkt, --experimental-bundle, und eine dokumentierte Konfigurationsoption, experimental.bundledDev: true:
import { defineConfig } from 'vite'
export default defineConfig({
experimental: {
bundledDev: true,
},
})
Der Standard-Vite-Dev-Server ist ungebündelt: Jedes Quellmodul wird als eigene ESM-Datei ausgeliefert und der Browser löst den Import-Graph auf. Das hat Vite bei kleineren Apps schnell gemacht, aber sobald Apps über einige tausend Module hinauswuchsen, dominierte der Per-Module-Request-Overhead Cold Start und Full Reloads. Bundled Dev Mode behält die Dev-Server-Ergonomie (HMR, Plugin-Pipeline, Env-Vars), bündelt die App aber mit Rolldown vor und liefert die vorgebauten Chunks aus. Das Vite-Team misst 15x schnelleren Cold Start bei einer React-App mit 10 000 Komponenten, 10x schnellere Full Reloads und instant HMR unabhängig von der App-Größe; das Team von Linear berichtet 3x schnelleres Cold-Start-Rendering, ~40% schnellere Full Reloads und 10x weniger Netzwerk-Requests in ihrer App.
Das Feature bleibt experimentell, weil die Plugin-Oberfläche geformt wird. Die Release Notes weisen darauf hin, dass „bei Verwendung eines Drittanbieter-Plugins dieses eventuell nicht mit diesem Modus funktioniert" und der Fokus auf den Browser-seitigen Core-Features liegt; das Design-Dokument legt den geplanten Plugin-Vertrag offen. Zwei Follow-ups sind bereits in der nächsten 8.x-Linie gemerged: PR #22587 hat bundledDev in DevEnvironment eingefügt statt eine separate Unterklasse zu sein (in 8.1-beta.0 ausgeliefert), und PR #22617 stellt sicher, dass Inkremental-Build-Fehler im bundled-dev-Modus gemeldet statt verschluckt werden.
WASM ESM Integration und Chunk Import Map werden stabil
Die zwei großen Beta-Features gehen unverändert aus dem 8.1-beta.0-Branch in stable: PR #21779 implementiert den WASM-ESM-Integration-Entwurf der WebAssembly-Community-Group als direkte .wasm-Importe ohne ?init-Suffix, und PR #21580 ergänzt build.chunkImportMap, eine opt-in Build-Option, die Browser-Import-Maps verwendet, um Chunk-Hashes stabil zu halten, wenn sich nur eine Quelldatei ändert.
Das WASM-Feature ersetzt das alte Muster import init from './add.wasm?init'; const instance = await init(); durch import { add } from './add.wasm'. Vite parst das Binary, extrahiert Importe und Exporte und emittiert Glue-Code, der eine ordentlich typisierte WebAssembly.Module-Instanz zurückgibt. Die Legacy-Querystring-Suffixe ?init, ?url und ?raw funktionieren weiterhin, sodass bestehende Projekte nicht im Lockstep migrieren müssen. Das Feature ist heute unabhängig vom Browser-Support, da Vite weiterhin das Parsing und die Glue-Generation übernimmt; der Browser-seitige Spec standardisiert nur das langfristige Ziel.
Das Chunk-Import-Map-Feature wirkt auf einer anderen Skala: Es ist eine echte Cache-Stabilitätsverbesserung für Production-Builds, kein Dev-Server-Komfort. In einem Standard-Rolldown-Build enthält jeder Chunk-Dateinamen einen Content-Hash, und die Import-Anweisungen zeigen direkt auf die gehashte URL. Ändert sich eine einzige Quelldatei, bekommt jeder Chunk, der sie (direkt oder transitiv) importiert, einen neuen Hash, was durch den Import-Graph kaskadiert und mehr Chunks als nötig invalidiert. Import-Maps entkoppeln die Import-Anweisung von der Chunk-URL: Die Anweisung sagt import { x } from '/chunks/x.js', die Import-Map sagt /chunks/x.js wird zu /chunks/x-abc123.js aufgelöst, und wenn der Chunk-Inhalt unverändert bleibt, bleibt die gehashte URL gleich und der Browser verwendet sie erneut. Die Implementierung hängt von import.meta.resolve im Browser ab, daher funktioniert chunkImportMap nur in Browsern, die das unterstützen; das begleitende plugin-legacy deckt ältere Browser mit SystemJS ab.
Lightning CSS, einen Schritt näher am Default-Status
PR #21748 sorgt dafür, dass Vite die von Lightning CSS selbst deklarierten Plugin-Abhängigkeiten respektiert, und PR #18389 ergänzt die Unterstützung für externe CSS-Dateien, die in CSS-Dateien importiert werden. Beide Teile waren bereits als Lightning-CSS-Issues unterwegs (lightningcss#479 und lightningcss#877) und sind nun in Vite verdrahtet. Die Release Notes sagen, das Team „denkt darüber nach, den Default-CSS-Preprocessor im nächsten Major-Release auf Lightning CSS umzustellen". Um es jetzt auszuprobieren, setzt man css.transformer: 'lightningcss' in vite.config.js und gibt Feedback in vitejs/vite#13835.
server.fs.deny-Erweiterung
PR #22707 (sapphi.red, feat: extend server.fs.deny list with common files) verschärft den secure-by-default Dev-Server. Die Deny-Liste geht von ['.env', '.env.*', '*.{crt,pem}', '**/.git/**'] (Vite 8.0.x) zu ['.env', '.env.*', '*.{crt,pem,key,p12,pfx,cer,der}', '.npmrc', '.yarnrc.yml', '**/.git/**'] (Vite 8.1.0). Die neuen Einträge decken Schlüssel- und Zertifikats-Material in .key-, .p12-, .pfx-, .cer- und .der-Dateien ab (die gleiche Familie wie die bestehende .crt- und .pem-Abdeckung) plus die Credential-Dateien der Package-Manager .npmrc und .yarnrc.yml.
Die PR-Beschreibung stellt klar, dass das nicht als Vulnerability-Fix gerahmt ist: Es ist nicht möglich, jede sensible Datei abzudecken, aber man fügt die üblichen nach und nach hinzu, und die server.fs.deny-Liste ist dokumentiert, sodass man bei Bedarf weitere hinzufügen kann. In der Praxis verhindert diese Art von Änderung versehentliche Credential-Leaks, wenn ein Entwickler das Projekt-Wurzelverzeichnis ohne benutzerdefinierte server.fs.allow-Konfiguration ausliefert, was der Default für neue Projekte ist. Das Verhalten ist im Dev- und SSR-Modus identisch.
Tilde-gepinntes Rolldown
PR #22693 (use ~ for Rolldown) ist klein, aber für Ecosystem-Nutzer erwähnenswert. Die package.json von Vite pinnte rolldown zuvor als "rolldown": "1.1.1" (exakte Version); 8.1.0 pinnt es als "rolldown": "~1.1.1" (Tilde-Range, akzeptiert jedes 1.1.x). Die Motivation ist operativ: Rolldown veröffentlicht Patch-Releases in schnellerer Kadenz als Vite, und Vite musste rolldown für jeden Patch-Release manuell bumpen. Mit dem Tilde-Range fließen 1.1.2 (2026-06-18) und 1.1.3 (2026-06-24) über das Lockfile in Vite-Installationen ein, ohne dass ein eigener Vite-PR nötig ist.
Das Risiko ist die Versions-Drift im Tilde-Range: Ein Rolldown-Patch, der in 1.1.x landet und Verhalten ändert, könnte in einer Vite-Installation landen, ohne dass ein expliziter Vite-Release nötig ist. Die Mitigation ist, dass Patch-Semver als abwärtskompatibel gedacht ist und die Release-Kadenz des Vite-Teams schnell genug ist, um bei einem schlechten Rolldown-Patch innerhalb von ein bis zwei Tagen einen Vite-Patch nachzuschieben. Das 1.1.3-Release am selben Tag wie dieser Artikel zeigt den neuen Rhythmus: Ein Rolldown-Bugfix kann innerhalb weniger Stunden nach dem Merge in Vite-Installationen landen.
envFile: false-Deprecation-Warnung
PR #22555 ergänzt eine Runtime-Deprecation-Warnung, wenn envFile: false verwendet wird. Das Verhalten ändert sich nicht; das bestehende abwärtskompatible Mapping von envFile: false zu envDir: false bleibt erhalten. Die Motivation ist, dass envFile bereits in der Typdefinition als deprecated markiert war, der Runtime-Pfad jedoch still blieb, was die Migration für Nutzer der programmatischen API erschwerte und das Verhalten inkonsistent zu anderen deprecated Vite-Optionen ließ, die bei Verwendung warnen. Der Fix ist eine einzeilige Warnung plus passende Config-Tests; Nutzer, die bereits envDir: false verwenden, bekommen keine Warnung.
Weitere Änderungen zwischen Beta und Stable
Der CHANGELOG-Diff von 22 Commits zwischen v8.1.0-beta.0 und v8.1.0 besteht größtenteils aus Bug-Fixes plus dem Rolldown-1.1.2-Bump:
- PR #22714 behandelt fehlerhafte URIs im Memory-Files-Middleware.
- PR #22715 cachet Falsy-Werte in
perEnvironmentState, ein kleiner Correctness-Fix für Environments, die teure Arbeit bei jedem Request neu bewertet haben. - PR #22711 sorgt dafür, dass der Glob-HMR-Matcher die
caseSensitive-Option respektiert. - PR #22713 lässt das
nonce-Attribut auf Import-Maps weg, wenncspNoncenicht gesetzt ist (ein kleiner HTML-Correctness-Fix). - PR #22611 überspringt null-wertige Exports in der
expandGlobIds-Glob-Auflösung. - PR #22691 behält aufgelöste Build-Optionen als Getter, damit Plugins, die
config.buildintrospizieren, die aufgelösten Werte sehen. - PR #22706 verwendet literale envPrefix-Queries für Vite Task.
- PR #22736 inlinet den dev-id-Wert im CSS-Selector (eine kleine client-seitige Größenoptimierung).
- PR #22724 entfernt das ungenutzte
removeRawQuery-Utility. - PR #22692 benennt
chunkImportMap-bezogene Optionen um, sodass sie dierolldownOptions-Property verwenden. - PR #22695 aktualisiert Rolldown auf 1.1.2.
Warum das Timing zählt
Das Vite-Team hat den announcing-vite8-1-Post am selben Tag wie das Release veröffentlicht, was eine schnellere Bearbeitung von „Beta" zu „Stable + Ankündigung" ist als üblich (acht Tage für 8.1 gegenüber etwa drei Wochen für die 8.0-Linie). Die Zahl von 41,6M wöchentlichen Downloads erinnert daran, dass Vite nun in der gleichen Installationsbasis wie React liegt, und die Bundled-Dev-Mode-Metriken sind die Art von Schlagzeilen, die einen Minor-Line-Bump allein rechtfertigen.
Für Nutzer auf der stabilen Vite-8-Linie ist das Upgrade npm install -D vite@8.1.0 plus eine einmalige Config-Anpassung, falls WebSocket-Optionen unter server.hmr gesetzt sind. Für Nutzer, die noch auf Vite 7 oder älter sind, decken die Release Notes zu Vite 8 stable die Rolldown-Migration und die größeren Änderungen der Plugin-Oberfläche ab. Die 8.1-Linie ist heute das empfohlene stabile Ziel für neue Projekte, mit 8.2 und 9.0 bereits als Meilensteine im Vite-Repo offen.
