Rolldown v1.1.4, published on 2026-07-01T14:02:02Z, is a four-week-later reversal of the headline change in Rolldown v1.1.0 (2026-06-03), which made experimental.lazyBarrel default-on with a note that the opt-out was planned for removal in a future release. The 1.1.4 release flips the default back to off, forces the option off in dev mode on top of the existing force-off for treeshake, and ships a 19-bug-fix tail. The underlying correctness gap is collected in the new tracking issue #10085 "Tracking strictExecutionOrder correctness and architecture issues", which opened the day after the release. 1.1.4 is the first release in the 1.1.x line to touch the lazyBarrel config surface since the 1.1.0 default-flip.
The previous Rolldown 1.1.0 lazyBarrel article covered the original default-flip: lazyBarrel went from a tucked-away opt-in to a default-on behaviour, the headline of the 1.1.0 release. The article also said "the opt-out flag is planned for removal in a future release" and "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 walks back the planned removal and instead ships the "open an issue" path: the opt-in stays, the default flips, and the underlying detection logic is the subject of the new tracking issue.
What 1.1.4 changes in the config
The single feature entry in 1.1.4 is one line in the changelog: "disable experimental.lazyBarrel by default (#10071) by @shulaoda". The PR body is four paragraphs. The first paragraph is the news: "temporarily disables experimental.lazyBarrel by default again (back to opt-in)." The second is the reason: "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." The third is the technical fix: "Default experimental.lazyBarrel to false in is_lazy_barrel_enabled. Update the @default JSDoc tag on the lazyBarrel option to false." The fourth is the docs change: "Update the lazy barrel docs to reflect that it is now disabled by default and document how to opt in."
The second config-side change in 1.1.4 is a dev-mode fix, also by @shulaoda. PR #10060 merges the three dev-mode overrides into a single block in prepare_build_context.rs: incrementalBuild is forced on, treeshake is forced off, and lazyBarrel is forced off. The PR is explicit about why the third override is needed: "Dev mode requires treeshaking to be disabled, and lazy barrel relies on treeshaking, so it must be disabled as well." The override flows through is_lazy_barrel_enabled(), so a single Some(false) setting flips the feature off in the module task, the module loader, and the flat options. The fix removes the inconsistency where a dev build was running a barrel-aware treeshake pass against a graph where general treeshake was off.
The root cause being tracked
The 1.1.4 release ships one day before the team opened the canonical issue #10085 for the underlying gap. The issue title is "Tracking strictExecutionOrder correctness and architecture issues", and the body is a structured list of two specific bugs and two architecture problems. The first bug is a onDemandWrapping miss: top-level import-binding reads are not accounted for, so a pure-looking module can be moved across a mutation and capture the wrong live export value. The second bug is a ExecutionOrderSensitive miss: the current check asks whether a statement itself can do something observable, but it misses reads whose observed value depends on earlier module execution. The two architecture problems are StmtEvalAnalyzer short-circuiting on side effects (so it cannot also be used as a complete collector of order facts) and the broader pattern of wrapping broadly and then unwrapping, instead of deriving wrapping obligations from execution-order-sensitive facts and graph dependencies.
The companion issue #10077 "Support tree shaking and lazy barrel under dev mode" is the dev-mode follow-up: dev mode forces treeshake off because the original implementation could not guarantee correctness with the on-demand execution model, and lazyBarrel relies on treeshake. The fix is to bring the dev-mode treeshake correctness up to the production-mode level, after which lazyBarrel can be on in dev too. The two issues are the work that unblocks the next default-flip.
The 19 bug fixes on top
The 1.1.4 release ships 19 bug fixes, all on top of an unchanged 1.1.x API surface. The headliners are three preserveModules JSON default-export fixes (#10056, #10020, #9996), which together keep the full JSON interface under preserveModules and bail the JSON default split when the object escapes. The chunk-facade retention fix (#9997) keeps the entry facade when a shared chunk holds another entry's module, which prevents a real production-build edge case where a re-exported entry would lose its facade. The deconflict fix (#9921) renames CJS-wrapped locals that shadow chunk-root bindings, which fixes a class of variable-shadowing issues in mixed CJS/ESM builds. The treeshake fixes cover await classification (#9987), namespace member access side effects (#9986), JSON default mutation bailouts (#9972), and computed-key side effects on namespace member access. The dev-mode fixes include catchable init errors in lazy-compiled modules (#9981) and a plugin metadata fix (#9991, reverted by #10005).
The release also ships the usual performance tail, headlined by disabling preserve_parens across all parse paths (#10057), inlining declared_symbols with SmallVec (#9920), and packing TaggedSymbolRef into 8 bytes (#9919). The release upgrades to oxc 0.138.0 and migrates AST construction to per-type factories, which is a prerequisite for the strictExecutionOrder correctness work that is now being scoped under the new tracking issue.
Why this matters for the Rolldown roadmap
The 1.1.4 release is a small version bump that ships a meaningful signal about how the project handles flagship-feature regressions. The default-flip on experimental.lazyBarrel was the most visible change in the 1.1.0 release notes, and the four-week window between the default-flip and the reversal is the kind of cadence that produces trust: the team turned the feature on, took the bug reports, opened a tracking issue, and walked the default back rather than papering over the gap. The opt-in path is unchanged, so any project that was already on the opt-in path has nothing to do. Any project that picked up the default-on behaviour implicitly gets the more conservative legacy path. The team has not committed to a release window for the re-enable, but the tracking issues are public and the work is scoped.
The Vite 8.1 stable release, which shipped on 2026-06-23 and runs on Rolldown 1.1.2, inherits the default-on behaviour for now. The first Vite release that ships on Rolldown 1.1.4 will pick up the default-flip revert and the dev-mode fix, and will be the release that closes the 1.1.0-to-1.1.4 arc for Vite users. The Vite 8 / Rolldown era retrospective from March is the long-form context for why this matters: Vite 8 was the first release where the dev server runs on the same Rolldown graph as the production build, and the lazyBarrel default-flip was a step towards making that graph the fastest in the ecosystem. The 1.1.4 reversal is a step back on the speed curve and a step forward on the correctness curve; the team is not slowing down on either, but they are not shipping a fast-but-wrong default either.
