---
title: "Rolldown 1.1.4 Disables `experimental.lazyBarrel` by Default Again, One Month After 1.1.0 Made It Default-On"
description: "Rolldown [v1.1.4](https://github.com/rolldown/rolldown/releases/tag/v1.1.4), published 2026-07-01T14:02:02Z, ships one feature change and 19 bug fixes. The feature change is a partial reversal of the [v1.1.0 default-flip](https://github.com/rolldown/rolldown/releases/tag/v1.1.0) that landed on 2026-06-03: `experimental.lazyBarrel` is now disabled by default again, after four weeks of correctness reports against the default-on behaviour. The release also hardens the dev-mode path by forcing `lazyBarrel` off whenever `experimental.devMode` is set (PR [#10060](https://github.com/rolldown/rolldown/pull/10060)), on top of the existing force-off for `treeshake`. The default-flip revert (PR [#10071](https://github.com/rolldown/rolldown/pull/10071)) and the dev-mode fix both author as one line each: \"disable `experimental.lazyBarrel` by default\" and \"fix(dev): disable lazy barrel in dev mode\", and the root-cause tracking is the new [issue #10085](https://github.com/rolldown/rolldown/issues/10085) \"Tracking strictExecutionOrder correctness and architecture issues\", opened the day after the release. The release follows [Rolldown v1.1.3](https://github.com/rolldown/rolldown/releases/tag/v1.1.3) (2026-06-24) and is the first release since 1.1.0 to touch the lazyBarrel config surface."
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) reverts the v1.1.0 default-flip on `experimental.lazyBarrel`: the option goes from default `true` back to default `false`, so a build that does not set `experimental.lazyBarrel` no longer gets the barrel-pruning treeshake pass. The opt-in path is unchanged, so any project that explicitly set `experimental.lazyBarrel: true` in 1.1.x still gets the same behaviour in 1.1.4. PR [#10071](https://github.com/rolldown/rolldown/pull/10071) describes the reversal in one sentence: \"temporarily disables `experimental.lazyBarrel` by default again (back to opt-in)\", and points at a single unresolved `strictExecutionOrder` tree shaking issue as the root cause."
  - "The release also hardens dev mode by forcing `lazyBarrel` off whenever `experimental.devMode` is set (PR [#10060](https://github.com/rolldown/rolldown/pull/10060)). Dev mode already forced `treeshake: false`; with lazyBarrel still on, the bundler was running a barrel-aware treeshake pass against a graph where general treeshake was off, which produced inconsistent code-gen between dev and prod. The fix merges the three dev-mode overrides (`incrementalBuild`, `treeshake`, `lazyBarrel`) into one block in `prepare_build_context.rs` so the rationale (\"dev mode requires treeshake, so lazy barrel is off too\") is documented at the override site."
  - "The root cause is being tracked in the new [issue #10085](https://github.com/rolldown/rolldown/issues/10085) \"Tracking strictExecutionOrder correctness and architecture issues\", opened 2026-07-02. The issue lists two specific bugs (`onDemandWrapping` missing top-level import-binding reads, `ExecutionOrderSensitive` missing reads whose value depends on earlier module execution) and two architecture problems (`StmtEvalAnalyzer` short-circuits on side-effects, `strictExecutionOrder + onDemandWrapping` wraps broadly and then unwraps). The companion [issue #10077](https://github.com/rolldown/rolldown/issues/10077) tracks the dev-mode follow-up. The release notes ship with 19 bug fixes on top of the lazyBarrel reversal, headlined by three `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)) and a chunk-facade retention fix ([#9997](https://github.com/rolldown/rolldown/pull/9997))."
faq:
  - question: "What changed in Rolldown 1.1.4?"
    answer: "Rolldown 1.1.4 (published 2026-07-01) ships one feature change and 19 bug fixes. The feature change is the lazyBarrel default-flip revert: `experimental.lazyBarrel` is back to default `false` after being default `true` for four weeks in 1.1.0, 1.1.1, 1.1.2, and 1.1.3. The dev-mode path is also hardened so that `lazyBarrel` is forced off whenever `experimental.devMode` is set, alongside the existing force-off for `treeshake`. The 19 bug fixes cover the `preserveModules` JSON default-export path (three fixes in #10056, #10020, #9996), a chunk-facade retention fix for shared chunks that hold another entry's module (#9997), a deconflict fix for CJS-wrapped locals that shadow chunk-root bindings (#9921), treeshaking fixes for JSON default split, await classification, namespace member access side effects, and computed-key side effects, and a string of smaller dev-mode, addon-hook, and plugin-metadata fixes. The release also upgrades to oxc 0.138.0 and migrates AST construction to per-type factories."
  - question: "Why was `experimental.lazyBarrel` flipped back to default off?"
    answer: "PR [#10071](https://github.com/rolldown/rolldown/pull/10071) states the reason in one line: \"temporarily disables `experimental.lazyBarrel` by default again (back to opt-in).\" The follow-on sentence is the real signal: \"Only one unresolved issue is left: a `strictExecutionOrder` tree shaking issue, which is the root cause of the lazy barrel runtime error.\" The default-flip is a temporary state while the team fixes the `strictExecutionOrder` correctness gap; once the gap is closed, the team will re-enable lazyBarrel by default in a future release. The `experimental.lazyBarrel` option itself is unchanged; only the default value of `is_lazy_barrel_enabled()` flips from `true` back to `false`."
  - question: "How does the dev-mode fix change behaviour?"
    answer: "PR [#10060](https://github.com/rolldown/rolldown/pull/10060) explains the dev-mode inconsistency: dev mode already forces `treeshake: false`, but `is_lazy_barrel_enabled()` defaulted to `true`, so the bundler was running a barrel-aware treeshake pass against a graph where general treeshake was off. The two `experimental.dev_mode.is_some()` checks (one forcing `incremental_build` on, the other forcing `treeshake` off) were merged into a single block in `prepare_build_context.rs` that also forces `experimental.lazy_barrel = Some(false)`. The override flows through the same `is_lazy_barrel_enabled()` reader that the rest of the build reads, so the feature is off everywhere for dev mode in one move. The PR also merges the two `experimental.dev_mode.is_some()` checks into a single block so all dev-mode overrides are co-located."
  - question: "What is the root cause being tracked in issue #10085?"
    answer: "The [tracking issue #10085](https://github.com/rolldown/rolldown/issues/10085), opened 2026-07-02, is the canonical list of `strictExecutionOrder` correctness bugs and architecture problems. The two bugs are: `onDemandWrapping` does not account for top-level import-binding reads, so a pure-looking module can be moved across a mutation and capture the wrong live export value, and the current `ExecutionOrderSensitive` check mostly asks whether a statement itself can do something observable but misses reads whose observed value depends on earlier module execution. The two architecture problems are: `StmtEvalAnalyzer` short-circuits once it finds a tree-shaking side effect, so it cannot also be used as a complete collector of order facts, and `strictExecutionOrder + onDemandWrapping` starts from wrapping almost everything and tries to unwrap, instead of deriving wrapping obligations from execution-order-sensitive facts and graph dependencies. Closing the bugs unblocks the default-flip; closing the architecture problems unblocks future lazyBarrel work in dev mode."
  - question: "Do I need to change my rolldown config when I upgrade to 1.1.4?"
    answer: "No, if you did not set `experimental.lazyBarrel` explicitly. The default flip means that a build that was getting lazyBarrel under 1.1.0 through 1.1.3 now gets the legacy non-lazy path under 1.1.4. The opt-in path is unchanged, so a project that explicitly set `experimental.lazyBarrel: true` in 1.1.x gets the same behaviour in 1.1.4. The only thing that changes is the default for projects that did not touch the option. If you were relying on the default-on lazyBarrel for a build speedup, the practical advice is to opt in explicitly: `export default { experimental: { lazyBarrel: true } }`. The release notes confirm that the opt-in path is the same code path that was default-on in 1.1.0, with no extra configuration required."
  - question: "Will lazyBarrel flip back to default-on in a future release?"
    answer: "Yes, that is the explicit plan. PR #10071 says \"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 future release will be the one that ships the `strictExecutionOrder` correctness fixes tracked in #10085 and the dev-mode follow-up tracked in [issue #10077](https://github.com/rolldown/rolldown/issues/10077) \"Support tree shaking and lazy barrel under dev mode\". The team has not committed to a release window; the tracking issues do not carry a milestone. The release flow that produced 1.1.4 (default-flip revert + dev-mode fix + correctness tracker) is the playbook for the re-enable: ship the fix, flip the default, keep the opt-in path stable."
  - question: "Is Rolldown 1.1.4 safe to upgrade to today?"
    answer: "Yes. The release ships on a stable channel, the default-flip revert is a relaxation (builds that were on the default-on path go back to the legacy non-lazy path, which is the more conservative behaviour), and the bug fixes in the release are all conservative patches on top of an unchanged 1.1.x API surface. The 19 bug fixes are the kind of patch tail that any actively maintained bundler ships in a minor release. The one observation to flag: the Vite integration uses Rolldown 1.1.2 today, so the lazyBarrel default-flip revert and the dev-mode fix do not land in Vite until Vite ships on Rolldown 1.1.4 (Vite 8.1.3 still pulls Rolldown 1.1.2 in the latest published release notes). The recommended transition is to upgrade Rolldown directly if you embed it, and to wait for the next Vite patch release if you go through Vite."
---

[Rolldown v1.1.4](https://github.com/rolldown/rolldown/releases/tag/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](https://github.com/rolldown/rolldown/releases/tag/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](https://github.com/rolldown/rolldown/issues/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](/articles/2026-06-05--rolldown-1-1-0-lazybarrel-default-tsconfig) 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](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/issues/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](https://github.com/rolldown/rolldown/issues/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](https://github.com/rolldown/rolldown/pull/10056), [#10020](https://github.com/rolldown/rolldown/pull/10020), [#9996](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/pull/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](https://github.com/rolldown/rolldown/pull/9987)), namespace member access side effects ([#9986](https://github.com/rolldown/rolldown/pull/9986)), JSON default mutation bailouts ([#9972](https://github.com/rolldown/rolldown/pull/9972)), and computed-key side effects on namespace member access. The dev-mode fixes include catchable init errors in lazy-compiled modules ([#9981](https://github.com/rolldown/rolldown/pull/9981)) and a plugin metadata fix ([#9991](https://github.com/rolldown/rolldown/pull/9991), reverted by [#10005](https://github.com/rolldown/rolldown/pull/10005)).

The release also ships the usual performance tail, headlined by disabling `preserve_parens` across all parse paths ([#10057](https://github.com/rolldown/rolldown/pull/10057)), inlining `declared_symbols` with `SmallVec` ([#9920](https://github.com/rolldown/rolldown/pull/9920)), and packing `TaggedSymbolRef` into 8 bytes ([#9919](https://github.com/rolldown/rolldown/pull/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](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode), 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](/articles/2026-03-26-vite-8-rolldown-era) 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.