Vite 8 hat seine Bundler in Rolldown integriert – was ist dabei kaputtgegangen?

Jahrelang führte Vite heimlich zwei verschiedene Bundler – einen während der Entwicklung und einen für die Veröffentlichung. Rolldown beendet diese Trennung. Die Geschwindigkeitsvorteile sind real – genauso wie die Liste der Fehler.

Viele Teams kennen das Symptom, ohne die Ursache zu nennen: Der lokale Server zeigt grün an, die Produktion rot – und die Ursache liegt nicht in einem Tippfehler. Der Laufzeitumgebung, die während der Entwicklung Module bereitstellte, und die Toolkette, die sie für die Produktion verpackte, waren sich in einem Sonderfall uneinig. Bei Vite war diese Uneinigkeit strukturell bedingt: esbuild wurde während der Entwicklung verwendet, Rollup für die Produktion – und das Verbindungsmechanismus war gut genug, sodass die Unterschiede unsichtbar blieben – bis sie es plötzlich nicht mehr waren.

Vite 8 schließt diese Lücke mit einem einzigen Rust-Bundler: Rolldown. Die Benchmarks sind überzeugend – genauso wie die Liste der Anwendungen, die kaputtgingen, als die jahrelangen Besonderheiten beider Systeme plötzlich keinen Platz mehr zum Verstecken hatten. Nur wer beide Seiten kennt, kann ohne unerwartete Probleme upgraden.

Was hat sich in Vite 8 geändert

Der Ansatz mit zwei Engines war im Jahr 2020 vernünftig. Die Entwicklung eines völlig neuen Produktionsbundlers erfordert mehrere Jahre Arbeit. esbuild entwickelte sich bereits schnell weiter; Rollup verfügte bereits über ein eigenes Plugin-Ökosystem. Sie miteinander zu verbinden war pragmatisch. Doch das führte auch zu anhaltenden Risiken: Zwei Tools, die dieselben Quellen unterschiedlich verarbeiten, insbesondere bei der Interoperabilität mit CommonJS – der unhandlichen Brücke zwischen require()-Modulen und modernen ESM-Modulen.

Rolldown löst dieses gesamte Problem in einer einzigen Engine. Es handelt sich um eine Implementierung in Rust mit einer auf Rollup basierenden Plugin-API (die meisten Plugins funktionieren weiterhin). Die Version 1.0 wurde am 7. Mai 2026 als stabil veröffentlicht, wobei die API festgelegt wurde, um sie für produktive Anwendungen einzusetzen. Vite 8 selbst stabilisierte sich am 12. März 2026 und machte Rolldown standardmäßig – ohne dass eine aktive Auswahl mehr möglich war. Die Transformationen und Minifizierungen, die früher in esbuild stattfanden, laufen nun in Oxc, einem weiteren Toolchain aus Rust von VoidZero (dieselbe Firma hinter Rolldown).

Überschrift: Produktionsbuilds können 10–30-mal schneller bereitgestellt werden als klassische Rollups. Der Entwicklungsmodus ist eine weniger beachtete Entwicklung. Der „Full Bundle Mode“ packt die Anwendung im Entwicklungsmodus genauso wie in der Produktion zusammen, anstatt rohe ESM-Dateien einzeln bereitzustellen. Frühe Ergebnisse deuten auf eine etwa 3-mal schnellere Kaltstartzeit, ca. 40 % schnellere vollständige Neu laden sowie rund 10-mal weniger Netzwerkanfragen hin. Große Codebasen hatten bereits das unbundelte ESM im Entwicklungsmodus überwunden; dies schließt diese Lücke.

Der strukturelle Vorteil ist einfacher: Ein einziger Engine für beide Modi. Die alten Fehlerarten vom Typ „Entwicklungs-Interoperabilität ≠ Produktions-Interoperabilität“ werden unmöglich, da es keinen zweiten Bundler mehr gibt, mit dem man sich streiten könnte.

Was tatsächlich schiefgelaufen ist

Die Migration war nicht kostenlos, und das zu verschweigen hilft niemandem, der einen Upgrade plant.

Eine strengere Interoperabilität von CommonJS hat Pakete beschädigt. Mehrdeutige CJS-Exporte werden anders behandelt als im alten esbuild+Rollup-Setup. Ohne module.exports.__esModule und ohne eine default-Eigenschaft kann Rolldown einen Import an das gesamte module.exports-Objekt binden, anstatt wie die tolerantere Variante einen Standardwert zu vermuten:

// This used to just work under Vite 7 (esbuild + Rollup)
import DOMPurify from 'dompurify';
DOMPurify.sanitize(input);
// Under Rolldown's stricter CJS interop, this can throw:
// TypeError: e is not a function
// because the import resolved to the whole exports object,
// not the function you expected

Gefährliche Eigenschaft dieser Klasse: CI-Systeme übersehen sie in der Regel. jsdom oder emulierte Testsätze führen selten das echte Produktionsartefakt aus. Fehler treten auf, wenn ein Browser die kompilierte Ausgabe lädt. Vites legacy.inconsistentCjsInterop: true stellt das alte, tolerantere Verhalten wieder her, während Sie nach der Abhängigkeit suchen.

manualChunks ist für advancedChunks veraltet. Der Ersatz erfolgt nicht durch einfaches Suchen und Ersetzen. Einige Teams haben aufgrund von Nebeneffekten bei der Neugruppierung den Fehler ReferenceError: Cannot access 'x' before initialization festgestellt, wobei in mindestens einem Bericht 575 Chunks unter der Standard-Rolldown-Chunking-Strategie vor manueller Anpassung beschrieben wurden.

// Old, now-deprecated approach
build: {
  rollupOptions: {
    output: {
      manualChunks: {
        vendor: ['react', 'react-dom'],
      },
    },
  },
}
// Rolldown's replacement - more powerful, but a real migration
build: {
  rolldownOptions: {
    output: {
      advancedChunks: {
        groups: [
          { name: 'vendor', test: /node_modules/, priority: 100 },
        ],
      },
    },
  },
}

Außerhalb des App-Codes: Die native Rust-Bindung von Rolldown konnte in StackBlitz WebContainers nicht geladen werden, wodurch viele Browser-Playground-Vorlagen unbrauchbar wurden, bis die Projekte Vite 7 festlegten, während die Entwickler das Problem behebten.

Sichere Migrations-Checkliste

Teams, die den Umstieg abgeschlossen haben, konzentrieren sich auf konkrete Schritte und nicht einfach nur auf „Upgrade und hoffen“.

Rätselhafte Fehler vom Typ „Vite 7 funktionierte, Vite 8 versagt“: Versuchen Sie zunächst experimental: { enableNativePlugin: false }. Native Rust-Plugins sind jetzt standardmäßig aktiv; ihr Deaktivieren behebt einen erstaunlich großen Anteil an unklaren Fehlern.

Laden Sie vor dem Deploy das echte Produktions-Bundle in einem echten Browser. jsdom erkennt die CJS-Interoperabilitätsklasse nur, wenn Sie das gebaute Artefakt ausführen.

Betrachten Sie manualChunks → advancedChunks als ein eigenständiges Projekt mit eigener Testphase. Fehler bezüglich der Chunk-Reihenfolge scheinen in Ordnung zu sein, bis ein bestimmter Pfad ausgeführt wird.

Verringern Sie das Risiko mit rolldown-vite (Vite 7 + Rolldown-Voransicht) in Ihrer Codebasis, bevor Sie auf Vite 8 wechseln.

Falls eine kritische Abhängigkeit noch nicht für Rolldown bereit ist, ist es eine sinnvolle Entscheidung, bei dieser Build-Version weiterhin Vite 7 zu verwenden – das ist besser, als unter Zeitdruck fragile Workarounds zu erfinden.

Wer auf Probleme stoßen könnte

Standard-ESM-Abhängigkeiten sowie einfaches/standardmäßiges Chunking: Die Aktualisierungen verlaufen in der Regel reibungslos, und allein die Kompatibilität lohnt sich bereits. Bei benutzerdefinierten manualChunks, hybriden CJS/ESM-Paketen oder ungewöhnlichen Hosts (Browser-Sandboxen, WebContainers) sollten Sie Zeit für die Migration einplanen und das Ergebnis im Browser testen. Solche Fehler bestehen in den CI-Tests weiterhin, tauchen aber erst bei echten Nutzern in den tatsächlichen Bundles auf.

Höhere Lektion

Sobald zwei Systeme, die früher gegenseitig ihre Grenzen abdeckten, zu einem zusammengefügt werden, treten plötzlich alle zuvor unsichtbaren Nahtstellen zutage. Das bedeutet nicht, dass die Vereinigung falsch war. Die Gleichwertigkeit von Entwicklung und Produktion stellt eine echte strukturelle Verbesserung dar, und die Geschwindigkeitswerte bleiben konstant. Es bedeutet lediglich, dass „Wir haben die Meinungsverschiedenheiten beseitigt“ und „Während des Übergangs wird eine Welle spezifischer, auffindbarer Fehler auftreten“ dasselbe Phänomen an unterschiedlichen Tagen sind. Skepsis gegenüber Rolldown ist die falsche Haltung; Skepsis gegenüber einer grünen CI ohne ein im Browser geladenes Produktionspaket hingegen ist richtig.

Was auf die Migrationsanfrage geschrieben werden sollte

Schreiben Sie den Upgrade-Prozess als ingenieurtechnische Änderung mit Akzeptanzkriterien, und nicht als Anhebung einer Abhängigkeit.

Vorgeschlagene Kriterien:

1. Die Produktionskompilierung erfolgt unter Rolldown mit denselben öffentlichen Ressourcen, wie erwartet.

Falls ein Kriterium nicht erfüllt wird, sollte man weiterhin Vite 7 oder rolldown-vite verwenden, bis das Kriterium erfüllt ist. Die Bereitstellung eines schnelleren Bundlers, der in der Produktion Probleme verursacht, stellt keinen Leistungsvorteil dar.

Warum Paritätsschäden persönlich wirken

Entwickler vertrauen auf den lokalen Server. Wenn der lokale Server und die Produktionsversion aufhören, miteinander in Konflikt zu geraten, treten Fehler, die zuvor durch diese Konflikte verdeckt wurden, an einem Ort zutage. Das kann den Eindruck erwecken, als hätte ein „Rolldown“ Fehler eingeführt, die bereits immer in der Mehrdeutigkeit von CJS oder den Chunk-Graphen vorhanden waren. Die Benennung dieses Musters verringert die Panik – man jagt nicht willkürlichen Regressionen nach, sondern bringt die durch das Dual-Engine-Modell verdeckten Probleme ans Licht.

Bewahren Sie die Geschwindigkeitswerte bei. Beibehalten Sie das Design mit einem einzigen Engine. Verwechseln Sie jedoch nicht ein grünes Testergebnis mit dem Beweis, dass das erstellte Produkt funktioniert.