Rolldown 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 (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 « 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 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) 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 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 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 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, #10020, #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) 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) 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), les side effects d'accès aux membres de namespace (#9986), les bailouts de mutation de default JSON (#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) et un fix de metadata de plugin (#9991, annulé par #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), l'inlining de declared_symbols avec SmallVec (#9920), et le packing de TaggedSymbolRef sur 8 octets (#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, 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 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.
