---
title: "Vite 8.1.0 stable bringt Bundled Dev Mode (15x schnellerer Start bei 10k-React-Komponenten), WASM-ESM-Importe und Chunk Import Map, erweitert server.fs.deny um .npmrc und private Schlüssel"
description: "Vite 8.1.0 stable, veröffentlicht am 2026-06-23 vom Vite-Team (announcing-vite8-1), hebt Bundled Dev Mode von einem experimentellen Flag auf einen dokumentierten --experimental-bundle-Einstiegspunkt (15x schnellerer Cold Start bei einer React-App mit 10 000 Komponenten, 10x schnellere Full Reloads; Linear meldet 3x schnelleres Cold-Start-Rendering, ~40% schnellere Full Reloads), stabilisiert die WASM-ESM-Integration mit direkten .wasm-Importen und build.chunkImportMap aus der 8.1-Beta vom 2026-06-15, bringt Lightning CSS mit External-CSS-in-CSS und Plugin-Dateiabhängigkeiten einen Schritt näher an den Default-Status, aktualisiert Rolldown auf 1.1.2 (1.1.3 folgt am selben Tag), pinnt rolldown mit einem Tilde-Range, sodass Patch-Releases ohne Vite-PR durchfließen, erweitert server.fs.deny um .npmrc, .yarnrc.yml und *.{key,p12,pfx,cer,der} und gibt eine Runtime-Deprecation-Warnung für envFile: false aus."
date: 2026-06-24
image: "/images/heroes/2026-06-24--vite-8-1-stable-bundled-dev-mode.png"
author: lschvn
tags: ["tooling", "performance"]
tldr:
  - "Vite 8.1.0 stable ([announcing-vite8-1](https://vite.dev/blog/announcing-vite8-1)) ist am 2026-06-23 aus demselben [8.1-beta.0-Branch](/articles/2026-06-15--vite-8-1-beta-wasm-esm-chunk-importmap) wie am 2026-06-15 veröffentlicht worden. Bundled Dev Mode wechselt von einem undokumentierten Flag zu einem dokumentierten experimentellen Einstiegspunkt: `--experimental-bundle` auf der CLI oder `experimental.bundledDev: true` in vite.config.js. Das Vite-Team misst 15x schnelleren Cold Start bei einer React-App mit 10 000 Komponenten, 10x schnellere Full Reloads, und HMR bleibt instant unabhängig von der App-Größe. Linear berichtet 3x schnelleres Cold-Start-Rendering, ~40% schnellere Full Reloads und 10x weniger Netzwerk-Requests."
  - "Das Release stabilisiert die zwei großen Beta-Features: direkte `.wasm`-Importe über WASM ESM Integration (kein `?init`-Suffix mehr) und `build.chunkImportMap`, das Browser-Import-Maps nutzt, um Chunk-Hashes stabil zu halten, wenn sich nur eine Quelldatei ändert. Außerdem bringt es eine `caseSensitive`-Option für `import.meta.glob`, `html.additionalAssetSources` für Custom Elements, Lightning-CSS-Unterstützung für Plugin-Dateiabhängigkeiten und External-CSS-in-CSS (ein Schritt näher am Default-Status) und benennt `server.hmr`-Optionen in `server.ws` um (der einzige Breaking Change der Linie)."
  - "Weitere konkrete Änderungen: `server.fs.deny` erweitert den Default von `['.env', '.env.*', '*.{crt,pem}', '**/.git/**']` um `.npmrc`, `.yarnrc.yml` und `*.{key,p12,pfx,cer,der}` (PR #22707); rolldown wird mit einem Tilde-Range (`~1.1.1`) gepinnt, sodass 1.1.2 und 1.1.3 ohne Vite-PR durchfließen (PR #22693); `envFile: false` gibt jetzt eine Runtime-Deprecation-Warnung aus (PR #22555); und Rolldown 1.1.3 erscheint am selben Tag und fixt einen `defer_drop`-Crash auf dem Browser-Main-Thread sowie ein Reentrancy-Problem beim Close im Watch-Mode."
faq:
  - question: "Was ist das Top-Feature von Vite 8.1.0 stable?"
    answer: "Bundled Dev Mode. Das Feature liegt nicht mehr hinter einem Flag ohne Doku: 8.1 dokumentiert es als `--experimental-bundle` auf der CLI oder `experimental.bundledDev: true` in vite.config.js und erklärt den Tradeoff in einem dedizierten Design-Dokument (vitejs/vite#22746). Der Dev-Server bündelt jetzt die App für das Browser-Target vor und liefert die vorgebauten Chunks aus, statt das ungebündelte Modul-Graph zu streamen wie Vite es seit v1 tut. 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; Linear berichtet 3x schnelleres Cold-Start-Rendering, ~40% schnellere Full Reloads und 10x weniger Netzwerk-Requests in Production-Tests. Die zwei weiteren stabilen Features sind direkte .wasm-Importe über WASM ESM Integration und `build.chunkImportMap` für stabiles Chunk-Caching."
  - question: "Wie unterscheidet sich Bundled Dev Mode vom Standard-Vite-Dev-Server?"
    answer: "Der Standard-Vite-Dev-Server ist ungebündelt: Er liefert jedes Quellmodul als eigene ESM-Datei aus und lässt den Browser den Import-Graph auflösen. 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. Die Tradeoffs: Drittanbieter-Plugins, die auf Per-Module-Transforms angewiesen sind, brauchen eventuell Updates, und der Fokus liegt aktuell auf Browser-seitigen Core-Features. Das Feature bleibt experimentell, weil die Plugin-Oberfläche noch geformt wird; siehe vitejs/vite#22746 für die Roadmap."
  - question: "Was ändert sich zwischen Vite 8.1-beta.0 und 8.1.0 stable?"
    answer: "Der Großteil der Arbeit fand in der Beta statt. Das Stable-Release ergänzt drei konkrete Features, Fixes und ein strukturelles Pin. Die Features: `server.fs.deny` wird um `.npmrc`, `.yarnrc.yml` und Zertifikats- bzw. Schlüssel-Erweiterungen (`key, p12, pfx, cer, der`) erweitert, für einen weniger überraschenden secure-by-default Dev-Server (PR #22707). Die Fixes: ein Malformed-URI-Crash im Memory-Files-Middleware (PR #22714), ein `perEnvironmentState`-Cache, der Falsy-Werte verlor (PR #22715), ein Glob-HMR-Matcher, der die `caseSensitive`-Option ignorierte (PR #22711), und ein `bundled-dev`-Inkremental-Build-Fehler, der verschluckt statt gemeldet wurde (PR #22617). Die strukturelle Änderung: rolldown wird jetzt mit einem Tilde-Range (`~1.1.1`) gepinnt statt mit einer exakten Version, sodass Patch-Releases wie 1.1.2 (die Vite 8.1 ausliefert) und 1.1.3 (am selben Tag erschienen) ohne Vite-PR pro Release einfließen."
  - question: "Sind direkte .wasm-Importe und build.chunkImportMap produktionsreif?"
    answer: "Ja, beide haben die 8.1-Beta durchlaufen und sind jetzt in 8.1.0 stabil. Direkte .wasm-Importe nutzen den WASM-ESM-Integration-Entwurf der WebAssembly-Community-Group, daher entspricht der Import-Pfad dem künftigen Browser-seitigen Spec; Vite übernimmt bis dahin weiterhin das Parsen des Binaries und die Glue-Generation. `build.chunkImportMap` baut auf Rolldowns experimentellem chunkImportMap-Feature auf und hängt von `import.meta.resolve` im Browser ab, gilt also nicht für ältere Browser; das begleitende plugin-legacy deckt diese mit SystemJS ab. Die bekannten Caveats: `experimental.renderBuiltUrl` funktioniert aktuell nicht mit chunkImportMap, und die Optimierung gilt noch nicht für CSS und Assets, nur für JavaScript-Chunks."
  - question: "Was deckt die server.fs.deny-Erweiterung konkret ab?"
    answer: "Die Default-Liste von `server.fs.deny` 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: Man kann nicht jede sensible Datei abdecken, aber man fügt die üblichen nach und nach hinzu, und die Liste ist als Override-Oberfläche dokumentiert. Projekte mit strengeren Anforderungen können `server.fs.deny` weiterhin explizit setzen."
  - question: "Hat Vite 8.1 Breaking Changes?"
    answer: "Einen: das Rename `server.hmr` zu `server.ws`, das bereits in 8.1-beta.0 gelandet ist. Alle WebSocket-bezogenen Optionen (host, port, clientPort, path, timeout, overlay) wandern von `server.hmr` zu `server.ws`, und `server.hmr` wird zu einem booleschen Toggle. Die Migration ist mechanisch: Den alten `server.hmr: { host, port, ... }`-Block in `server.ws: { host, port, ... }` plus einen booleschen `server.hmr` aufteilen, falls nötig. Es gibt auch eine sanfte Runtime-Deprecation: `envFile: false` gibt jetzt eine Warnung aus (PR #22555), aber das bestehende abwärtskompatible Mapping von `envFile: false` zu `envDir: false` bleibt erhalten."
  - question: "Was ist in Rolldown 1.1.2 und 1.1.3 enthalten?"
    answer: "Rolldown 1.1.2 (2026-06-18) aktualisiert oxc_resolver auf 11.21.3, sodass `compilerOptions.paths` für Importer aufgelöst wird, deren Erweiterung explizit im `include` eines tsconfig gelistet ist (z. B. `src/**/*.vue`, `src/**/*.svelte`). Das entsperrt das create-vite-Default-Layout für Vue + TS mit Solution-Style-Root plus referenziertem tsconfig.app.json, das `paths` und `include` deklariert. Rolldown 1.1.3 (2026-06-24, am selben Tag wie dieser Artikel) liefert zehn Fixes: einen `defer_drop`-Crash auf dem Browser-Main-Thread (#9942), einen CamelCase-Bug für verschachtelte Werte in der Config (#9933), einen `--help`-Anzeigebug (#9941), einen preserveModules-Re-Export-Bug (#9934), einen Close-Reentrancy-Fix im Watch-Mode (#9904), einen Git-for-Windows-Fix für Symlink-als-Regular-File (#9915), das Abbrechen anstehender Full Reloads bei Build-Fehlern (#9903), das Weiterreichen von Plugin-Meta an die `name`-Funktion der codeSplitting-Gruppen (#9267), das Ausliefern von Assets, die während HMR und Lazy Compile emittiert werden (#9815), sowie einen Dry-Run-Release, der Binding-Packages nicht mehr veröffentlicht (#9866)."
  - question: "Wie sieht der Upgrade-Pfad von Vite 8.0 aus?"
    answer: "Vite 8.1.0 ist ein non-breaking Release für Projekte, die ihre `server.hmr`-Config bereits zu `server.ws` migriert haben. Wer noch auf der 8.0.x-Linie ist, führt `npm install -D vite@8.1.0` (oder `bun add -D vite@8.1.0`) aus und nimmt bei Bedarf eine einmalige Config-Anpassung vor, falls WebSocket-Optionen unter `server.hmr` gesetzt sind. Das Release bringt außerdem eine sicherheitsrelevante Default-Änderung: `server.fs.deny` blockiert jetzt `.npmrc`, `.yarnrc.yml` und einen erweiterten Satz an Zertifikats- bzw. Schlüsseldateien, daher müssen Projekte, die diese Dateien bisher über den Dev-Server ausgeliefert haben (ein ungewöhnliches Muster, aber möglich für Credential-Loading-Demos), sie explizit zu `server.fs.allow` hinzufügen."
---

[Vite 8.1.0 stable](https://github.com/vitejs/vite/releases/tag/v8.1.0), veröffentlicht am 2026-06-23 von github-actions aus dem v8.1.0-Tag ([Commit 63b1489](https://github.com/vitejs/vite/commit/63b1489), `release: v8.1.0`), ist das erste Feature-Release auf dem [stabilen Vite-8-Branch](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks) 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](https://github.com/vitejs/vite/blob/v8.1.0/packages/vite/CHANGELOG.md) 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](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks). Der [Announcement-Post](https://vite.dev/blog/announcing-vite8-1) 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](https://github.com/vitejs/vite/discussions/22746), der nicht mehr ein Flag ohne Doku ist. Es gibt jetzt einen dedizierten CLI-Einstiegspunkt, `--experimental-bundle`, und eine dokumentierte Konfigurationsoption, `experimental.bundledDev: true`:

```ts [vite.config.js]
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](https://linear.app) 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](https://github.com/vitejs/vite/discussions/22746) legt den geplanten Plugin-Vertrag offen. Zwei Follow-ups sind bereits in der nächsten 8.x-Linie gemerged: [PR #22587](https://github.com/vitejs/vite/issues/22587) hat `bundledDev` in `DevEnvironment` eingefügt statt eine separate Unterklasse zu sein (in 8.1-beta.0 ausgeliefert), und [PR #22617](https://github.com/vitejs/vite/issues/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](/articles/2026-06-15--vite-8-1-beta-wasm-esm-chunk-importmap) in stable: [PR #21779](https://github.com/vitejs/vite/issues/21779) implementiert den [WASM-ESM-Integration](https://github.com/WebAssembly/esm-integration)-Entwurf der WebAssembly-Community-Group als direkte `.wasm`-Importe ohne `?init`-Suffix, und [PR #21580](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/issues/21748) sorgt dafür, dass Vite die von Lightning CSS selbst deklarierten Plugin-Abhängigkeiten respektiert, und [PR #18389](https://github.com/vitejs/vite/issues/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](https://github.com/parcel-bundler/lightningcss/issues/479) und [lightningcss#877](https://github.com/parcel-bundler/lightningcss/issues/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](https://github.com/vitejs/vite/discussions/13835).

## `server.fs.deny`-Erweiterung

[PR #22707](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/blob/v8.1.0/packages/vite/CHANGELOG.md) 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](https://github.com/vitejs/vite/issues/22714) behandelt fehlerhafte URIs im Memory-Files-Middleware.
- [PR #22715](https://github.com/vitejs/vite/issues/22715) cachet Falsy-Werte in `perEnvironmentState`, ein kleiner Correctness-Fix für Environments, die teure Arbeit bei jedem Request neu bewertet haben.
- [PR #22711](https://github.com/vitejs/vite/issues/22711) sorgt dafür, dass der Glob-HMR-Matcher die `caseSensitive`-Option respektiert.
- [PR #22713](https://github.com/vitejs/vite/issues/22713) lässt das `nonce`-Attribut auf Import-Maps weg, wenn `cspNonce` nicht gesetzt ist (ein kleiner HTML-Correctness-Fix).
- [PR #22611](https://github.com/vitejs/vite/issues/22611) überspringt null-wertige Exports in der `expandGlobIds`-Glob-Auflösung.
- [PR #22691](https://github.com/vitejs/vite/issues/22691) behält aufgelöste Build-Optionen als Getter, damit Plugins, die `config.build` introspizieren, die aufgelösten Werte sehen.
- [PR #22706](https://github.com/vitejs/vite/issues/22706) verwendet literale envPrefix-Queries für Vite Task.
- [PR #22736](https://github.com/vitejs/vite/issues/22736) inlinet den dev-id-Wert im CSS-Selector (eine kleine client-seitige Größenoptimierung).
- [PR #22724](https://github.com/vitejs/vite/issues/22724) entfernt das ungenutzte `removeRawQuery`-Utility.
- [PR #22692](https://github.com/vitejs/vite/issues/22692) benennt `chunkImportMap`-bezogene Optionen um, sodass sie die `rolldownOptions`-Property verwenden.
- [PR #22695](https://github.com/vitejs/vite/issues/22695) aktualisiert Rolldown auf 1.1.2.

## Warum das Timing zählt

Das Vite-Team hat den [announcing-vite8-1-Post](https://github.com/vitejs/vite/blob/v8.1.0/docs/blog/announcing-vite8-1.md) 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](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks) 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](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks) 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.