--- title: "Rolldown 1.1.4 Deaktiviert `experimental.lazyBarrel` Wieder als Standard, Einen Monat Nachdem 1.1.0 Es Standardmäßig Aktiviert Hatte" description: "Rolldown [v1.1.4](https://github.com/rolldown/rolldown/releases/tag/v1.1.4), veröffentlicht am 2026-07-01T14:02:02Z, liefert eine Feature-Änderung und 19 Fehlerbehebungen. Die Feature-Änderung ist eine teilweise Rücknahme des [Standard-Flips der v1.1.0](https://github.com/rolldown/rolldown/releases/tag/v1.1.0) vom 2026-06-03: `experimental.lazyBarrel` ist nach vier Wochen Korrekturmeldungen gegen das standardmäßig aktivierte Verhalten wieder standardmäßig deaktiviert. Das Release härtet außerdem den Dev-Mode-Pfad, indem `lazyBarrel` auf off gezwungen wird, sobald `experimental.devMode` gesetzt ist (PR [#10060](https://github.com/rolldown/rolldown/pull/10060)), zusätzlich zum bestehenden Force-off für `treeshake`. Die Standard-Flip-Rücknahme (PR [#10071](https://github.com/rolldown/rolldown/pull/10071)) und der Dev-Mode-Fix autorisieren sich jeweils in einer Zeile: „disable `experimental.lazyBarrel` by default“ und „fix(dev): disable lazy barrel in dev mode“, und die Verfolgung der Grundursache ist das neue [Issue #10085](https://github.com/rolldown/rolldown/issues/10085) „Tracking strictExecutionOrder correctness and architecture issues“, eröffnet am Tag nach dem Release. Das Release folgt auf [Rolldown v1.1.3](https://github.com/rolldown/rolldown/releases/tag/v1.1.3) (2026-06-24) und ist das erste Release seit 1.1.0, das die lazyBarrel-Konfigurationsoberfläche anfasst." date: 2026-07-03 image: "/images/heroes/2026-07-03--rolldown-1-1-4-lazybarrel-disabled-default.png" author: lschvn tags: ["tooling", "javascript"] tldr: - "Rolldown [v1.1.4](https://github.com/rolldown/rolldown/releases/tag/v1.1.4) (2026-07-01) nimmt den Standard-Flip der v1.1.0 auf `experimental.lazyBarrel` zurück: Die Option wechselt vom Standard `true` zurück zum Standard `false`, sodass ein Build, der `experimental.lazyBarrel` nicht setzt, den Tree-Shake-Pass für das Beschneiden von Barrels nicht mehr erhält. Der Opt-in-Pfad ist unverändert, sodass jedes Projekt, das in 1.1.x explizit `experimental.lazyBarrel: true` gesetzt hat, in 1.1.4 das gleiche Verhalten erhält. PR [#10071](https://github.com/rolldown/rolldown/pull/10071) beschreibt die Rücknahme in einem Satz: „temporarily disables `experimental.lazyBarrel` by default again (back to opt-in)“, und verweist auf ein einziges ungelöstes `strictExecutionOrder`-Tree-Shake-Problem als Grundursache." - "Das Release härtet außerdem den Dev-Mode, indem `lazyBarrel` auf off gezwungen wird, sobald `experimental.devMode` gesetzt ist (PR [#10060](https://github.com/rolldown/rolldown/pull/10060)). Der Dev-Mode zwang bereits `treeshake: false`; bei weiterhin aktivem lazyBarrel führte der Bundler einen Barrel-bewussten Tree-Shake-Pass auf einem Graphen aus, auf dem das allgemeine Tree-Shaking deaktiviert war, was zu inkonsistentem Code-Gen zwischen Dev und Prod führte. Der Fix führt die drei Dev-Mode-Overrides (`incrementalBuild`, `treeshake`, `lazyBarrel`) in einem einzigen Block in `prepare_build_context.rs` zusammen, sodass die Begründung („dev mode requires treeshaking, so lazy barrel is off too“) an der Override-Stelle dokumentiert ist." - "Die Grundursache wird im neuen [Issue #10085](https://github.com/rolldown/rolldown/issues/10085) „Tracking strictExecutionOrder correctness and architecture issues“ verfolgt, eröffnet am 2026-07-02. Das Issue listet zwei spezifische Bugs (`onDemandWrapping` berücksichtigt keine Top-Level-Import-Binding-Reads, `ExecutionOrderSensitive` verfehlt Reads, deren Wert von einer früheren Modulausführung abhängt) und zwei Architekturprobleme (`StmtEvalAnalyzer` schließt bei Side Effects kurz, `strictExecutionOrder + onDemandWrapping` wrappt breit und entwrappt dann). Das Schwester-[Issue #10077](https://github.com/rolldown/rolldown/issues/10077) verfolgt die Dev-Mode-Nacharbeit. Die Release Notes liefern 19 Fehlerbehebungen zusätzlich zur lazyBarrel-Rücknahme, angeführt von drei `preserveModules`-JSON-Default-Export-Fixes ([#10056](https://github.com/rolldown/rolldown/pull/10056), [#10020](https://github.com/rolldown/rolldown/pull/10020), [#9996](https://github.com/rolldown/rolldown/pull/9996)) und einem Chunk-Facade-Retention-Fix ([#9997](https://github.com/rolldown/rolldown/pull/9997))." faq: - question: "Was hat sich in Rolldown 1.1.4 geändert?" answer: "Rolldown 1.1.4 (veröffentlicht am 2026-07-01) liefert eine Feature-Änderung und 19 Fehlerbehebungen. Die Feature-Änderung ist die Rücknahme des lazyBarrel-Standard-Flips: `experimental.lazyBarrel` ist nach vier Wochen als `true` in 1.1.0, 1.1.1, 1.1.2 und 1.1.3 wieder standardmäßig `false`. Der Dev-Mode-Pfad wird außerdem gehärtet, sodass `lazyBarrel` gezwungen wird, off zu sein, sobald `experimental.devMode` gesetzt ist, neben dem bestehenden Force-off für `treeshake`. Die 19 Fehlerbehebungen decken den `preserveModules`-JSON-Default-Export-Pfad ab (drei Fixes in #10056, #10020, #9996), einen Chunk-Facade-Retention-Fix für geteilte Chunks, die das Modul eines anderen Entries halten (#9997), einen Deconflict-Fix für CJS-umhüllte Locals, die Chunk-Root-Bindings verschatteten (#9921), Tree-Shake-Fixes für JSON-Default-Split, await-Klassifikation, Side Effects von Namespace-Member-Zugriffen und Computed-Key-Side-Effects sowie eine Reihe kleinerer Dev-Mode-, Addon-Hook- und Plugin-Metadata-Fixes. Das Release aktualisiert außerdem auf oxc 0.138.0 und migriert die AST-Konstruktion zu Per-Type-Factories." - question: "Warum wurde `experimental.lazyBarrel` wieder standardmäßig auf off geflippt?" answer: "PR [#10071](https://github.com/rolldown/rolldown/pull/10071) nennt den Grund in einer Zeile: „temporarily disables `experimental.lazyBarrel` by default again (back to opt-in).“ Der folgende Satz ist das eigentliche Signal: „Only one unresolved issue is left: a `strictExecutionOrder` tree shaking issue, which is the root cause of the lazy barrel runtime error.“ Die Rücknahme ist ein temporärer Zustand, während das Team die `strictExecutionOrder`-Korrekturlücke schließt; sobald die Lücke geschlossen ist, wird das Team lazyBarrel in einem zukünftigen Release wieder standardmäßig aktivieren. Die Option `experimental.lazyBarrel` selbst ist unverändert; nur der Standardwert von `is_lazy_barrel_enabled()` flippt von `true` auf `false`." - question: "Wie verändert der Dev-Mode-Fix das Verhalten?" answer: "PR [#10060](https://github.com/rolldown/rolldown/pull/10060) erklärt die Dev-Mode-Inkonsistenz: Der Dev-Mode zwang bereits `treeshake: false`, aber `is_lazy_barrel_enabled()` blieb standardmäßig `true`, sodass der Bundler einen Barrel-bewussten Tree-Shake-Pass auf einem Graphen ausführte, auf dem das allgemeine Tree-Shaking deaktiviert war. Die beiden `experimental.dev_mode.is_some()`-Checks (einer zwingt `incremental_build` auf on, der andere zwingt `treeshake` auf off) wurden in einem einzigen Block in `prepare_build_context.rs` zusammengeführt, der auch `experimental.lazy_barrel = Some(false)` erzwingt. Das Override fließt durch denselben `is_lazy_barrel_enabled()`-Reader, den auch der Rest des Builds liest, sodass das Feature im Dev-Mode an einer einzigen Stelle überall ausgeschaltet wird. Die PR führt außerdem die beiden `experimental.dev_mode.is_some()`-Checks in einem einzigen Block zusammen, damit alle Dev-Mode-Overrides kolokalisiert sind." - question: "Was ist die in Issue #10085 verfolgte Grundursache?" answer: "Das [Tracking-Issue #10085](https://github.com/rolldown/rolldown/issues/10085), eröffnet am 2026-07-02, ist die kanonische Liste der `strictExecutionOrder`-Korrektheitsbugs und Architekturprobleme. Die beiden Bugs sind: `onDemandWrapping` berücksichtigt keine Top-Level-Import-Binding-Reads, sodass ein rein aussehendes Modul über eine Mutation hinweg verschoben werden und den falschen Live-Export-Wert einfangen kann, und der aktuelle `ExecutionOrderSensitive`-Check fragt vor allem, 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 kurz, sobald er einen Tree-Shake-Side-Effect findet, sodass er nicht auch als vollständiger Sammler von Ordnungsfakten dienen kann, und `strictExecutionOrder + onDemandWrapping` wrappt zunächst breit und versucht dann zu entwrappen, anstatt Wrapping-Pflichten aus ausführungsordnungsempfindlichen Fakten und Graphabhängigkeiten abzuleiten. Das Schließen der Bugs entsperrt den Standard-Flip; das Schließen der Architekturprobleme entsperrt die zukünftige lazyBarrel-Arbeit im Dev-Mode." - question: "Muss ich meine rolldown-Konfiguration ändern, wenn ich auf 1.1.4 aktualisiere?" answer: "Nein, wenn Sie `experimental.lazyBarrel` nicht explizit gesetzt hatten. Der Standard-Flip bedeutet, dass ein Build, der unter 1.1.0 bis 1.1.3 lazyBarrel erhielt, unter 1.1.4 den alten Nicht-Lazy-Pfad erhält. Der Opt-in-Pfad ist unverändert, sodass ein Projekt, das in 1.1.x explizit `experimental.lazyBarrel: true` gesetzt hatte, in 1.1.4 das gleiche Verhalten erhält. Das Einzige, was sich ändert, ist der Standardwert für Projekte, die die Option nicht angefasst hatten. Wenn Sie sich auf das standardmäßig aktivierte lazyBarrel für eine Build-Beschleunigung verlassen hatten, lautet der praktische Rat, es explizit zu aktivieren: `export default { experimental: { lazyBarrel: true } }`. Die Release Notes bestätigen, dass der Opt-in-Pfad derselbe Codepfad ist, der in 1.1.0 standardmäßig aktiviert war, ohne zusätzliche Konfiguration." - question: "Wird lazyBarrel in einem zukünftigen Release wieder standardmäßig aktiviert?" answer: "Ja, das ist der explizite Plan. PR #10071 sagt „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.“ Das zukünftige Release wird jenes sein, das die in #10085 verfolgten `strictExecutionOrder`-Korrekturen und die Dev-Mode-Nacharbeit im [Issue #10077](https://github.com/rolldown/rolldown/issues/10077) „Support tree shaking and lazy barrel under dev mode“ liefert. Das Team hat kein Release-Fenster zugesagt; die Tracking-Issues tragen keinen Milestone. Der Release-Flow, der 1.1.4 hervorgebracht hat (Standard-Flip-Rücknahme + Dev-Mode-Fix + Korrektheits-Tracker), ist das Playbook für die Reaktivierung: Fix liefern, Standard flippen, Opt-in-Pfad stabil halten." - question: "Ist es sicher, heute auf Rolldown 1.1.4 zu aktualisieren?" answer: "Ja. Das Release wird auf einem stabilen Kanal ausgeliefert, die Standard-Flip-Rücknahme ist eine Relaxation (Builds, die auf dem Standardpfad waren, fallen auf den alten konservativeren Nicht-Lazy-Pfad zurück), und die Fehlerbehebungen im Release sind alles konservative Patches auf einer unveränderten 1.1.x-API-Oberfläche. Die 19 Fehlerbehebungen sind die Art Patch-Schwanz, die jeder aktiv gepflegte Bundler in einem Minor-Release ausliefert. Die einzige Beobachtung, die es zu melden gilt: Die Vite-Integration verwendet derzeit Rolldown 1.1.2, daher kommen die lazyBarrel-Standard-Flip-Rücknahme und der Dev-Mode-Fix erst dann in Vite an, wenn Vite auf Rolldown 1.1.4 ausgeliefert wird (Vite 8.1.3 zieht in den zuletzt veröffentlichten Release Notes weiterhin Rolldown 1.1.2). Der empfohlene Übergang ist, Rolldown direkt zu aktualisieren, wenn Sie es einbetten, und auf den nächsten Vite-Patch-Release zu warten, wenn Sie über Vite gehen." --- [Rolldown v1.1.4](https://github.com/rolldown/rolldown/releases/tag/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](https://github.com/rolldown/rolldown/releases/tag/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](https://github.com/rolldown/rolldown/issues/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](/articles/2026-06-05--rolldown-1-1-0-lazybarrel-default-tsconfig) 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](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/issues/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](https://github.com/rolldown/rolldown/issues/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](https://github.com/rolldown/rolldown/pull/10056), [#10020](https://github.com/rolldown/rolldown/pull/10020), [#9996](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/pull/9987)), Side Effects von Namespace-Member-Zugriffen ([#9986](https://github.com/rolldown/rolldown/pull/9986)), JSON-Default-Mutations-Bailouts ([#9972](https://github.com/rolldown/rolldown/pull/9972)) und Computed-Key-Side-Effects bei Namespace-Member-Zugriffen ab. Die Dev-Mode-Fixes umfassen abfangbare Init-Fehler in Lazy-Compiled-Modulen ([#9981](https://github.com/rolldown/rolldown/pull/9981)) und einen Plugin-Metadata-Fix ([#9991](https://github.com/rolldown/rolldown/pull/9991), zurückgenommen durch [#10005](https://github.com/rolldown/rolldown/pull/10005)). Das Release liefert auch den üblichen Performance-Schwanz, angeführt von der Deaktivierung von `preserve_parens` über alle Parse-Pfade ([#10057](https://github.com/rolldown/rolldown/pull/10057)), dem Inlining von `declared_symbols` mit `SmallVec` ([#9920](https://github.com/rolldown/rolldown/pull/9920)) und dem Packen von `TaggedSymbolRef` auf 8 Bytes ([#9919](https://github.com/rolldown/rolldown/pull/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](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode), 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](/articles/2026-03-26-vite-8-rolldown-era) 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.