--- title: "Rolldown 1.1.4 Désactive `experimental.lazyBarrel` par Défaut, un Mois Après que 1.1.0 l'Ait Activé" description: "Rolldown [v1.1.4](https://github.com/rolldown/rolldown/releases/tag/v1.1.4), publié le 2026-07-01T14:02:02Z, embarque un changement de fonctionnalité et 19 corrections de bogues. Le changement de fonctionnalité est une annulation partielle du [bascule par défaut de la v1.1.0](https://github.com/rolldown/rolldown/releases/tag/v1.1.0) du 2026-06-03: `experimental.lazyBarrel` est à nouveau désactivé par défaut, après quatre semaines de signalements de correction sur le comportement par défaut. La release durcit aussi le chemin du mode dev en forçant `lazyBarrel` à off dès que `experimental.devMode` est défini (PR [#10060](https://github.com/rolldown/rolldown/pull/10060)), en plus du forçage existant à off pour `treeshake`. L'annulation de la bascule par défaut (PR [#10071](https://github.com/rolldown/rolldown/pull/10071)) et le fix du mode dev s'authentifient chacun en une ligne: « disable `experimental.lazyBarrel` by default » et « fix(dev): disable lazy barrel in dev mode », et le suivi de la cause racine est la nouvelle [issue #10085](https://github.com/rolldown/rolldown/issues/10085) « Tracking strictExecutionOrder correctness and architecture issues », ouverte le lendemain de la release. La release fait suite à [Rolldown v1.1.3](https://github.com/rolldown/rolldown/releases/tag/v1.1.3) (2026-06-24) et est la première release depuis 1.1.0 à toucher la surface de configuration lazyBarrel." 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) annule la bascule par défaut de la v1.1.0 sur `experimental.lazyBarrel`: l'option repasse de la valeur par défaut `true` à `false`, donc un build qui ne définit pas `experimental.lazyBarrel` n'obtient plus la passe de treeshake d'élagage des barrels. Le chemin opt-in reste inchangé, donc tout projet qui définissait explicitement `experimental.lazyBarrel: true` en 1.1.x obtient le même comportement en 1.1.4. La PR [#10071](https://github.com/rolldown/rolldown/pull/10071) décrit l'annulation en une phrase: « temporarily disables `experimental.lazyBarrel` by default again (back to opt-in) », et pointe vers un seul problème non résolu de treeshake `strictExecutionOrder` comme cause racine." - "La release durcit aussi le mode dev en forçant `lazyBarrel` à off dès que `experimental.devMode` est défini (PR [#10060](https://github.com/rolldown/rolldown/pull/10060)). Le mode dev forçait déjà `treeshake: false`; avec lazyBarrel encore activé, le bundler exécutait une passe de treeshake sensible aux barrels sur un graphe où le treeshake général était désactivé, ce qui produisait du code incohérent entre dev et prod. Le fix fusionne les trois overrides du mode dev (`incrementalBuild`, `treeshake`, `lazyBarrel`) dans un seul bloc dans `prepare_build_context.rs`, de sorte que la justification (« dev mode requires treeshaking, so lazy barrel is off too ») est documentée au site de l'override." - "La cause racine est suivie dans la nouvelle [issue #10085](https://github.com/rolldown/rolldown/issues/10085) « Tracking strictExecutionOrder correctness and architecture issues », ouverte le 2026-07-02. L'issue liste deux bogues spécifiques (`onDemandWrapping` qui manque les lectures de bindings d'imports top-level, `ExecutionOrderSensitive` qui manque les lectures dont la valeur dépend d'une exécution antérieure du module) et deux problèmes d'architecture (`StmtEvalAnalyzer` qui court-circuite sur les side effects, `strictExecutionOrder + onDemandWrapping` qui enveloppe largement puis désenveloppe). L'[issue #10077](https://github.com/rolldown/rolldown/issues/10077) sœur suit le suivi du mode dev. Les release notes embarquent 19 corrections de bogues en plus de l'annulation lazyBarrel, avec en tête trois fixes JSON default-export sous `preserveModules` ([#10056](https://github.com/rolldown/rolldown/pull/10056), [#10020](https://github.com/rolldown/rolldown/pull/10020), [#9996](https://github.com/rolldown/rolldown/pull/9996)) et un fix de rétention de facade de chunk ([#9997](https://github.com/rolldown/rolldown/pull/9997))." faq: - question: "Qu'est-ce qui a changé dans Rolldown 1.1.4 ?" answer: "Rolldown 1.1.4 (publié le 2026-07-01) embarque un changement de fonctionnalité et 19 corrections de bogues. Le changement de fonctionnalité est l'annulation de la bascule par défaut de lazyBarrel: `experimental.lazyBarrel` est de retour à `false` par défaut après avoir été à `true` pendant quatre semaines en 1.1.0, 1.1.1, 1.1.2, et 1.1.3. Le chemin du mode dev est aussi durci pour que `lazyBarrel` soit forcé à off dès que `experimental.devMode` est défini, en plus du forçage existant à off pour `treeshake`. Les 19 corrections couvrent le chemin `preserveModules` JSON default-export (trois fixes dans #10056, #10020, #9996), un fix de rétention de facade de chunk pour les chunks partagés qui détiennent le module d'une autre entrée (#9997), un fix de deconflict pour les locales CJS-wrapped qui masquent des bindings chunk-root (#9921), des fixes de treeshake pour le split par défaut JSON, la classification await, les side effects d'accès aux membres de namespace, et les side effects de computed keys, plus une série de petits fixes de mode dev, d'addon hooks et de metadata de plugin. La release met aussi à niveau vers oxc 0.138.0 et migre la construction AST vers des factories par type." - question: "Pourquoi `experimental.lazyBarrel` a-t-il été rebasculé à off par défaut ?" answer: "La PR [#10071](https://github.com/rolldown/rolldown/pull/10071) donne la raison en une ligne: « temporarily disables `experimental.lazyBarrel` by default again (back to opt-in) ». La phrase qui suit est le vrai signal: « Only one unresolved issue is left: a `strictExecutionOrder` tree shaking issue, which is the root cause of the lazy barrel runtime error. » L'annulation est un état temporaire pendant que l'équipe corrige le gap de correction `strictExecutionOrder`; une fois le gap fermé, l'équipe réactivera lazyBarrel par défaut dans une release future. L'option `experimental.lazyBarrel` elle-même est inchangée; seule la valeur par défaut de `is_lazy_barrel_enabled()` bascule de `true` à `false`." - question: "Comment le fix du mode dev change-t-il le comportement ?" answer: "La PR [#10060](https://github.com/rolldown/rolldown/pull/10060) explique l'incohérence du mode dev: le mode dev forçait déjà `treeshake: false`, mais `is_lazy_barrel_enabled()` restait à `true` par défaut, donc le bundler exécutait une passe de treeshake sensible aux barrels sur un graphe où le treeshake général était désactivé. Les deux checks `experimental.dev_mode.is_some()` (un forçant `incremental_build` à on, l'autre forçant `treeshake` à off) ont été fusionnés en un seul bloc dans `prepare_build_context.rs` qui force aussi `experimental.lazy_barrel = Some(false)`. L'override passe par le même lecteur `is_lazy_barrel_enabled()` que le reste du build, donc la feature est désactivée partout en mode dev en un seul mouvement. La PR fusionne aussi les deux checks `experimental.dev_mode.is_some()` en un seul bloc pour que tous les overrides du mode dev soient co-localisés." - question: "Quelle est la cause racine suivie dans l'issue #10085 ?" answer: "L'[issue de suivi #10085](https://github.com/rolldown/rolldown/issues/10085), ouverte le 2026-07-02, est la liste canonique des bogues de correction `strictExecutionOrder` et des problèmes d'architecture. Les deux bogues sont: `onDemandWrapping` ne tient pas compte des lectures de bindings d'imports top-level, donc un module d'apparence pure peut être déplacé à travers une mutation et capturer la mauvaise valeur d'export live, et le check `ExecutionOrderSensitive` actuel demande surtout si une instruction elle-même peut faire quelque chose d'observable mais manque les lectures dont la valeur observée dépend d'une exécution antérieure du module. Les deux problèmes d'architecture sont: `StmtEvalAnalyzer` court-circuite dès qu'il trouve un side effect de treeshake, donc il ne peut pas aussi servir de collecteur complet de faits d'ordre, et `strictExecutionOrder + onDemandWrapping` commence par envelopper presque tout puis essaie de désenvelopper, au lieu de dériver les obligations d'enveloppement des faits d'ordre d'exécution et des dépendances du graphe. Fermer les bogues débloque la bascule par défaut; fermer les problèmes d'architecture débloque le travail futur de lazyBarrel en mode dev." - question: "Dois-je changer ma configuration rolldown quand je passe à 1.1.4 ?" answer: "Non, si vous ne définissiez pas `experimental.lazyBarrel` explicitement. La bascule par défaut signifie qu'un build qui obtenait lazyBarrel sous 1.1.0 à 1.1.3 obtient maintenant le chemin non-lazy historique sous 1.1.4. Le chemin opt-in est inchangé, donc un projet qui définissait explicitement `experimental.lazyBarrel: true` en 1.1.x obtient le même comportement en 1.1.4. La seule chose qui change est la valeur par défaut pour les projets qui ne touchaient pas à l'option. Si vous comptiez sur lazyBarrel activé par défaut pour accélérer un build, le conseil pratique est de l'activer explicitement: `export default { experimental: { lazyBarrel: true } }`. Les release notes confirment que le chemin opt-in est le même chemin de code qui était activé par défaut en 1.1.0, sans configuration supplémentaire requise." - question: "Est-ce que lazyBarrel sera rebasculé à on par défaut dans une release future ?" answer: "Oui, c'est le plan explicite. La PR #10071 dit « 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. ». La release future sera celle qui livrera les corrections `strictExecutionOrder` suivies dans #10085 et le suivi du mode dev dans l'[issue #10077](https://github.com/rolldown/rolldown/issues/10077) « Support tree shaking and lazy barrel under dev mode ». L'équipe n'a pas engagé de fenêtre de release; les issues de suivi ne portent pas de milestone. Le flow de release qui a produit 1.1.4 (annulation de la bascule par défaut + fix du mode dev + issue de suivi de correction) est le playbook pour la réactivation: livrer le fix, basculer la valeur par défaut, garder le chemin opt-in stable." - question: "Est-il sûr de passer à Rolldown 1.1.4 aujourd'hui ?" answer: "Oui. La release est livrée sur un canal stable, l'annulation de la bascule par défaut est une relaxation (les builds qui étaient sur le chemin par défaut reviennent au chemin non-lazy historique, qui est le comportement le plus conservateur), et les corrections de bogues de la release sont toutes des patches conservateurs sur une surface d'API 1.1.x inchangée. Les 19 corrections sont le genre de tail de patch que n'importe quel bundler activement maintenu livre dans une release mineure. La seule observation à signaler: l'intégration Vite utilise Rolldown 1.1.2 aujourd'hui, donc l'annulation de la bascule par défaut de lazyBarrel et le fix du mode dev n'arrivent pas dans Vite tant que Vite ne livre pas sur Rolldown 1.1.4 (Vite 8.1.3 tire toujours Rolldown 1.1.2 dans les dernières release notes publiées). La transition recommandée est de mettre à jour Rolldown directement si vous l'embarquez, et d'attendre le prochain patch release de Vite si vous passez par Vite." --- [Rolldown v1.1.4](https://github.com/rolldown/rolldown/releases/tag/v1.1.4), publié le 2026-07-01T14:02:02Z, est une annulation quatre semaines plus tard du changement principal de [Rolldown v1.1.0](https://github.com/rolldown/rolldown/releases/tag/v1.1.0) (2026-06-03), qui avait rendu `experimental.lazyBarrel` activé par défaut avec une note indiquant que l'opt-out était prévu pour suppression dans une release future. La release 1.1.4 rebascule la valeur par défaut à off, force l'option à off en mode dev par-dessus le forçage existant à off pour `treeshake`, et embarque un tail de 19 corrections de bogues. Le gap de correction sous-jacent est collecté dans la nouvelle [issue de suivi #10085](https://github.com/rolldown/rolldown/issues/10085) « Tracking strictExecutionOrder correctness and architecture issues », ouverte le lendemain de la release. 1.1.4 est la première release de la ligne 1.1.x à toucher la surface de configuration lazyBarrel depuis la bascule par défaut de 1.1.0. L'[article précédent sur Rolldown 1.1.0 et lazyBarrel](/articles/2026-06-05--rolldown-1-1-0-lazybarrel-default-tsconfig) couvrait la bascule par défaut d'origine: lazyBarrel est passé d'un opt-in discret à un comportement activé par défaut, le titre de la release 1.1.0. L'article disait aussi « the opt-out flag is planned for removal in a future release » et « 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. » La 1.1.4 revient sur la suppression prévue et livre à la place le chemin « open an issue »: l'opt-in reste, la valeur par défaut bascule, et la logique de détection sous-jacente est le sujet de la nouvelle issue de suivi. ## Ce que 1.1.4 change dans la configuration L'unique entrée de fonctionnalité dans 1.1.4 est une ligne dans le changelog: « disable `experimental.lazyBarrel` by default ([#10071](https://github.com/rolldown/rolldown/pull/10071)) by @shulaoda ». Le corps de la PR fait quatre paragraphes. Le premier paragraphe est l'information: « temporarily disables `experimental.lazyBarrel` by default again (back to opt-in) ». Le deuxième est la raison: « 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. » Le troisième est le fix technique: « Default `experimental.lazyBarrel` to `false` in `is_lazy_barrel_enabled`. Update the `@default` JSDoc tag on the `lazyBarrel` option to `false`. » Le quatrième est le changement de documentation: « Update the lazy barrel docs to reflect that it is now disabled by default and document how to opt in. » Le deuxième changement côté configuration dans 1.1.4 est un fix du mode dev, aussi par @shulaoda. La PR [#10060](https://github.com/rolldown/rolldown/pull/10060) fusionne les trois overrides du mode dev en un seul bloc dans `prepare_build_context.rs`: `incrementalBuild` est forcé à on, `treeshake` est forcé à off, et `lazyBarrel` est forcé à off. La PR est explicite sur la raison du troisième override: « Dev mode requires treeshaking to be disabled, and lazy barrel relies on treeshaking, so it must be disabled as well. » L'override passe par `is_lazy_barrel_enabled()`, donc un seul `Some(false)` désactive la feature dans le module task, le module loader et les flat options. Le fix supprime l'incohérence où un build dev exécutait une passe de treeshake sensible aux barrels sur un graphe où le treeshake général était désactivé. ## La cause racine suivie La release 1.1.4 est livrée un jour avant que l'équipe n'ouvre l'[issue #10085](https://github.com/rolldown/rolldown/issues/10085) canonique pour le gap sous-jacent. Le titre de l'issue est « Tracking strictExecutionOrder correctness and architecture issues », et le corps est une liste structurée de deux bogues spécifiques et de deux problèmes d'architecture. Le premier bogue est un miss de `onDemandWrapping`: les lectures de bindings d'imports top-level ne sont pas prises en compte, donc un module d'apparence pure peut être déplacé à travers une mutation et capturer la mauvaise valeur d'export live. Le deuxième bogue est un miss de `ExecutionOrderSensitive`: le check actuel demande si une instruction elle-même peut faire quelque chose d'observable, mais il manque les lectures dont la valeur observée dépend d'une exécution antérieure du module. Les deux problèmes d'architecture sont: `StmtEvalAnalyzer` qui court-circuite sur les side effects (donc il ne peut pas aussi servir de collecteur complet de faits d'ordre), et le pattern plus large d'envelopper largement puis désenvelopper, au lieu de dériver les obligations d'enveloppement des faits d'ordre d'exécution et des dépendances du graphe. L'[issue #10077](https://github.com/rolldown/rolldown/issues/10077) sœur « Support tree shaking and lazy barrel under dev mode » est le suivi du mode dev: le mode dev force le treeshake à off parce que l'implémentation originale ne pouvait pas garantir la correction avec le modèle d'exécution à la demande, et lazyBarrel repose sur le treeshake. Le fix consiste à amener la correction du treeshake en mode dev au niveau du mode production, après quoi lazyBarrel pourra être activé en dev aussi. Les deux issues sont le travail qui débloque la prochaine bascule par défaut. ## Les 19 corrections de bogues en plus La release 1.1.4 embarque 19 corrections de bogues, toutes par-dessus une surface d'API 1.1.x inchangée. Les titres sont trois fixes JSON default-export sous `preserveModules` ([#10056](https://github.com/rolldown/rolldown/pull/10056), [#10020](https://github.com/rolldown/rolldown/pull/10020), [#9996](https://github.com/rolldown/rolldown/pull/9996)), qui ensemble conservent l'interface JSON complète sous `preserveModules` et court-circuitent le split par défaut JSON quand l'objet s'échappe. Le fix de rétention de facade de chunk ([#9997](https://github.com/rolldown/rolldown/pull/9997)) conserve la facade d'entrée quand un chunk partagé détient le module d'une autre entrée, ce qui prévient un vrai cas limite de build de production où une entrée ré-exportée perdrait sa facade. Le fix de deconflict ([#9921](https://github.com/rolldown/rolldown/pull/9921)) renomme les locales CJS-wrapped qui masquent des bindings chunk-root, ce qui corrige une catégorie de problèmes d'ombrage de variables dans les builds CJS/ESM mixtes. Les fixes de treeshake couvrent la classification await ([#9987](https://github.com/rolldown/rolldown/pull/9987)), les side effects d'accès aux membres de namespace ([#9986](https://github.com/rolldown/rolldown/pull/9986)), les bailouts de mutation de default JSON ([#9972](https://github.com/rolldown/rolldown/pull/9972)), et les side effects de computed keys sur les accès aux membres de namespace. Les fixes de mode dev incluent des erreurs d'init rattrapables dans les modules lazy-compiled ([#9981](https://github.com/rolldown/rolldown/pull/9981)) et un fix de metadata de plugin ([#9991](https://github.com/rolldown/rolldown/pull/9991), annulé par [#10005](https://github.com/rolldown/rolldown/pull/10005)). La release embarque aussi le tail de performance habituel, avec en tête la désactivation de `preserve_parens` sur tous les chemins de parse ([#10057](https://github.com/rolldown/rolldown/pull/10057)), l'inlining de `declared_symbols` avec `SmallVec` ([#9920](https://github.com/rolldown/rolldown/pull/9920)), et le packing de `TaggedSymbolRef` sur 8 octets ([#9919](https://github.com/rolldown/rolldown/pull/9919)). La release met à niveau vers oxc 0.138.0 et migre la construction AST vers des factories par type, ce qui est un prérequis pour le travail de correction `strictExecutionOrder` qui est maintenant scopé sous la nouvelle issue de suivi. ## Pourquoi cela compte pour la roadmap Rolldown La release 1.1.4 est un petit bump de version qui livre un signal significatif sur la façon dont le projet gère les régressions de fonctionnalités phares. La bascule par défaut sur `experimental.lazyBarrel` était le changement le plus visible des release notes 1.1.0, et la fenêtre de quatre semaines entre la bascule et l'annulation est le genre de cadence qui produit de la confiance: l'équipe a activé la feature, pris les rapports de bogues, ouvert une issue de suivi, et est revenue sur la valeur par défaut plutôt que de masquer le gap. Le chemin opt-in est inchangé, donc tout projet qui était déjà sur le chemin opt-in n'a rien à faire. Tout projet qui avait récupéré le comportement activé par défaut implicitement obtient le chemin historique plus conservateur. L'équipe n'a pas engagé de fenêtre de release pour la réactivation, mais les issues de suivi sont publiques et le travail est scopé. La [release stable Vite 8.1](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode), livrée le 2026-06-23 et tournant sur Rolldown 1.1.2, hérite du comportement activé par défaut pour l'instant. La première release Vite qui livrera sur Rolldown 1.1.4 récupérera l'annulation de la bascule par défaut et le fix du mode dev, et sera la release qui ferme l'arc 1.1.0-à-1.1.4 pour les utilisateurs de Vite. La [rétrospective de l'ère Vite 8 / Rolldown](/articles/2026-03-26-vite-8-rolldown-era) de mars est le contexte long format pour comprendre pourquoi cela compte: Vite 8 a été la première release où le serveur de dev tourne sur le même graphe Rolldown que le build de production, et la bascule par défaut de lazyBarrel était un pas vers le fait de rendre ce graphe le plus rapide de l'écosystème. L'annulation 1.1.4 est un pas en arrière sur la courbe de vitesse et un pas en avant sur la courbe de correction; l'équipe ne ralentit ni l'un ni l'autre, mais ne livre pas non plus une valeur par défaut rapide mais incorrecte.