Rolldown v1.1.4, veröffentlicht am 2026-07-01T14:02:02Z, ist eine vier Wochen spätere Rücknahme der Hauptänderung in Rolldown v1.1.0 (2026-06-03), die experimental.lazyBarrel standardmäßig aktiviert hatte mit dem Hinweis, dass das Opt-out für eine Entfernung in einem zukünftigen Release vorgesehen sei. Das Release 1.1.4 flippt den Standard zurück auf off, erzwingt die Option im Dev-Mode auf off zusätzlich zum bestehenden Force-off für treeshake, und liefert einen Schwanz von 19 Fehlerbehebungen. Die zugrundeliegende Korrekturlücke wird im neuen Tracking-Issue #10085 „Tracking strictExecutionOrder correctness and architecture issues“ gesammelt, das am Tag nach dem Release eröffnet wurde. 1.1.4 ist das erste Release in der 1.1.x-Linie, das die lazyBarrel-Konfigurationsoberfläche seit dem 1.1.0-Standard-Flip anfasst.
Der vorherige Artikel zu Rolldown 1.1.0 und lazyBarrel behandelte den ursprünglichen Standard-Flip: lazyBarrel wechselte von einem zurückhaltenden Opt-in zu einem standardmäßig aktivierten Verhalten, der Aufhänger des 1.1.0-Releases. Der Artikel sagte auch „the opt-out flag is planned for removal in a future release“ und „if you encounter a case where you need to disable it, the recommendation is to open an issue so the underlying detection logic can be improved instead.“ 1.1.4 nimmt die geplante Entferung zurück und liefert stattdessen den „open an issue“-Pfad: Das Opt-in bleibt, der Standard flippt, und die zugrundeliegende Erkennungslogik ist Gegenstand des neuen Tracking-Issues.
Was 1.1.4 in der Konfiguration ändert
Der einzige Feature-Eintrag in 1.1.4 ist eine Zeile im Changelog: „disable experimental.lazyBarrel by default (#10071) by @shulaoda“. Der PR-Body umfasst vier Absätze. Der erste Absatz ist die Nachricht: „temporarily disables experimental.lazyBarrel by default again (back to opt-in).“ Der zweite ist der Grund: „Only one unresolved issue is left: a strictExecutionOrder tree shaking issue, which is the root cause of the lazy barrel runtime error. Even though it could be fixed quickly, it doesn't hurt to turn the option off today and re-enable it by default in a future release once that issue is resolved.“ Der dritte ist der technische Fix: „Default experimental.lazyBarrel to false in is_lazy_barrel_enabled. Update the @default JSDoc tag on the lazyBarrel option to `false.“ Der vierte ist die Doku-Änderung: „Update the lazy barrel docs to reflect that it is now disabled by default and document how to opt in“.
Die zweite konfigurationsseitige Änderung in 1.1.4 ist ein Dev-Mode-Fix, ebenfalls von @shulaoda. PR #10060 führt die drei Dev-Mode-Overrides in einem einzigen Block in prepare_build_context.rs zusammen: incrementalBuild wird auf on gezwungen, treeshake wird auf off gezwungen, und lazyBarrel wird auf off gezwungen. Die PR ist explizit zum Grund des dritten Overrides: „Dev mode requires treeshaking to be disabled, and lazy barrel relies on treeshaking, so it must be disabled as well.“ Das Override fließt durch is_lazy_barrel_enabled(), sodass ein einziges Some(false) das Feature im Module Task, im Module Loader und in den Flat Options deaktiviert. Der Fix beseitigt die Inkonsistenz, bei der ein Dev-Build einen Barrel-bewussten Tree-Shake-Pass auf einem Graphen ausführte, auf dem das allgemeine Tree-Shaking deaktiviert war.
Die verfolgte Grundursache
Das Release 1.1.4 wird einen Tag vor dem kanonischen Issue #10085 ausgeliefert, das das Team für die zugrundeliegende Lücke eröffnet. Der Titel des Issues lautet „Tracking strictExecutionOrder correctness and architecture issues“, und der Body ist eine strukturierte Liste von zwei spezifischen Bugs und zwei Architekturproblemen. Der erste Bug ist ein onDemandWrapping-Miss: Top-Level-Import-Binding-Reads werden nicht berücksichtigt, sodass ein rein aussehendes Modul über eine Mutation hinweg verschoben werden und den falschen Live-Export-Wert einfangen kann. Der zweite Bug ist ein ExecutionOrderSensitive-Miss: Der aktuelle Check fragt, ob eine Anweisung selbst etwas Beobachtbares tun kann, verfehlt aber Reads, deren beobachteter Wert von einer früheren Modulausführung abhängt. Die beiden Architekturprobleme sind: StmtEvalAnalyzer schließt bei Side Effects kurz (sodass er nicht auch als vollständiger Sammler von Ordnungsfakten dienen kann), und das breitere Muster, zunächst breit zu wrappen und dann zu entwrappen, anstatt Wrapping-Pflichten aus ausführungsordnungsempfindlichen Fakten und Graphabhängigkeiten abzuleiten.
Das Schwester-Issue #10077 „Support tree shaking and lazy barrel under dev mode“ ist die Dev-Mode-Nacharbeit: Der Dev-Mode zwingt Tree-Shake auf off, weil die ursprüngliche Implementierung die Korrektheit mit dem On-Demand-Ausführungsmodell nicht garantieren konnte, und lazyBarrel baut auf Tree-Shake auf. Der Fix besteht darin, die Dev-Mode-Tree-Shake-Korrektheit auf das Niveau des Produktionsmodus zu bringen, woraufhin lazyBarrel auch im Dev aktiviert sein kann. Die beiden Issues sind die Arbeit, die den nächsten Standard-Flip entsperrt.
Die 19 Fehlerbehebungen zusätzlich
Das Release 1.1.4 liefert 19 Fehlerbehebungen, alle zusätzlich zu einer unveränderten 1.1.x-API-Oberfläche. Die Spitzenreiter sind drei preserveModules-JSON-Default-Export-Fixes (#10056, #10020, #9996), die zusammen das vollständige JSON-Interface unter preserveModules bewahren und den JSON-Default-Split kurzschließen, wenn das Objekt entkommt. Der Chunk-Facade-Retention-Fix (#9997) bewahrt die Entry-Facade, wenn ein geteilter Chunk das Modul eines anderen Entries hält, was einen echten Produktions-Build-Edge-Case verhindert, bei dem ein re-exportierter Entry seine Facade verlieren würde. Der Deconflict-Fix (#9921) benennt CJS-umhüllte Locals um, die Chunk-Root-Bindings verschatteten, was eine Klasse von Variablen-Schatten-Problemen in gemischten CJS/ESM-Builds behebt. Die Tree-Shake-Fixes decken die await-Klassifikation (#9987), Side Effects von Namespace-Member-Zugriffen (#9986), JSON-Default-Mutations-Bailouts (#9972) und Computed-Key-Side-Effects bei Namespace-Member-Zugriffen ab. Die Dev-Mode-Fixes umfassen abfangbare Init-Fehler in Lazy-Compiled-Modulen (#9981) und einen Plugin-Metadata-Fix (#9991, zurückgenommen durch #10005).
Das Release liefert auch den üblichen Performance-Schwanz, angeführt von der Deaktivierung von preserve_parens über alle Parse-Pfade (#10057), dem Inlining von declared_symbols mit SmallVec (#9920) und dem Packen von TaggedSymbolRef auf 8 Bytes (#9919). Das Release aktualisiert auf oxc 0.138.0 und migriert die AST-Konstruktion zu Per-Type-Factories, was eine Voraussetzung für die strictExecutionOrder-Korrektheitsarbeit ist, die nun unter dem neuen Tracking-Issue skopiert wird.
Warum dies für die Rolldown-Roadmap zählt
Das Release 1.1.4 ist ein kleiner Versionssprung, der ein bedeutsames Signal darüber liefert, wie das Projekt mit Flaggschiff-Feature-Regressionen umgeht. Der Standard-Flip auf experimental.lazyBarrel war die sichtbarste Änderung in den 1.1.0-Release Notes, und das Vier-Wochen-Fenster zwischen dem Flip und der Rücknahme ist die Art von Kadenz, die Vertrauen schafft: Das Team hat das Feature aktiviert, die Fehlerberichte aufgenommen, ein Tracking-Issue eröffnet und den Standard zurückgenommen, anstatt die Lücke zu übertünchen. Der Opt-in-Pfad ist unverändert, sodass jedes Projekt, das bereits auf dem Opt-in-Pfad war, nichts zu tun hat. Jedes Projekt, das das standardmäßig aktivierte Verhalten implizit erhalten hatte, bekommt den konservativeren alten Pfad. Das Team hat kein Release-Fenster für die Reaktivierung zugesagt, aber die Tracking-Issues sind öffentlich und die Arbeit ist skopiert.
Die Vite 8.1 Stable-Release, die am 2026-06-23 ausgeliefert wurde und auf Rolldown 1.1.2 läuft, erbt das standardmäßig aktivierte Verhalten vorerst. Das erste Vite-Release, das auf Rolldown 1.1.4 ausgeliefert wird, nimmt die Standard-Flip-Rücknahme und den Dev-Mode-Fix auf und wird das Release sein, das den 1.1.0-zu-1.1.4-Bogen für Vite-Nutzer schließt. Die Vite 8 / Rolldown-Ära Retrospektive vom März ist der Long-Form-Kontext, warum dies zählt: Vite 8 war das erste Release, bei dem der Dev-Server auf demselben Rolldown-Graphen lief wie der Produktions-Build, und der lazyBarrel-Standard-Flip war ein Schritt, diesen Graphen zum schnellsten im Ökosystem zu machen. Die 1.1.4-Rücknahme ist ein Schritt zurück auf der Geschwindigkeitskurve und ein Schritt vorwärts auf der Korrektheitskurve; das Team verlangsamt weder das eine noch das andere, liefert aber auch keinen schnellen, aber falschen Standard.
