Turbopack + `optimizePackageImports` tree-shakes a `sideEffects`-allowlisted, side-effect-only module (breaks `react-focus-lock`)

[sentience]

Link to the code that reproduces this issue

https://github.com/cultureamp/turbopack-sidecar-treeshaking-repro

To Reproduce

1. npm install
2. npm run build – ❌ Turbopack (Next's default bundler) — build FAILS at prerender: "Error: Sidecar medium not found"
3. npm run build:webpack – ✅ webpack — same config, builds fine

Current vs. Expected behavior

With experimental.optimizePackageImports containing both react-focus-on and react-focus-lock, a production Turbopack build tree-shakes react-focus-lock's side-effect-only sidecar module out of the bundle. That module's sole purpose is a registration side-effect (exportSidecar(mediumSidecar, FocusTrap)); with it gone, rendering any focus trap throws:

Error: Sidecar medium not found

react-focus-lock's package.json marks the module side-effectful via a sideEffects allowlist (["**/sidecar.js", "**/index.js"]), so it should be retained. webpack retains it; Turbopack drops it when the import is rewritten by optimizePackageImports.

Expected

optimizePackageImports should not cause a module in the target package's sideEffects allowlist to be dropped. Turbopack should honour sideEffects for side-effect-only (bare) imports even when the barrel import is rewritten by the optimization.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.5.0: Tue Jun  9 22:28:34 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6041
  Available memory (MB): 49152
  Available CPU cores: 14
Binaries:
  Node: 26.5.0
  npm: 11.17.0
  Yarn: N/A
  pnpm: 10.34.5
Relevant Packages:
  next: 16.3.0-canary.102 // Latest available version is detected (16.3.0-canary.102).
  eslint-config-next: N/A
  react: 19.2.8
  react-dom: 19.2.8
  typescript: N/A
Next.js Config:
  output: N/A


Note: Above-linked repro repo is on Next 16.2.11, but I've verified it still reproduces with the current canary.

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

next build (local)

Additional context

• Reproduces only in a production Turbopack build; next dev, next build --webpack, unit tests, and Storybook all pass — so it typically surfaces only in deployed apps.
• Impact is broad: optimizePackageImports is widely used (Next enables it by default for many packages; design systems add their own), and most modal/popover/menu components transitively use react-focus-on / react-focus-lock.
• react-remove-scroll uses the same sidecar pattern and is likely affected the same way.

[sentience]

Here's some root-cause analysis and a proposed from Claude. Apologies, I am not familiar with Rust, so I can't vouch for the quality of this proposed fix.

Root cause (traced into the Turbopack source)

It's an interaction between optimizePackageImports and how Turbopack resolves a module's sideEffects status — the optimizePackageImports list ends up overriding a dependency's own sideEffects allowlist.

1. optimizePackageImports becomes a blanket "side-effect-free" glob.

next-core passes the configured list straight through:

// crates/next-core/src/next_server/context.rs (and next_client/context.rs)
side_effect_free_packages_glob(next_config.optimize_package_imports())

which builds a glob matching every file in each listed package:

// turbopack/crates/turbopack/src/module_options/module_options_context.rs
// -> "**/node_modules/{react-focus-on,react-focus-lock,...}/**"
globs.push_str("**/node_modules/{");
globs.push_str(&side_effect_free_packages.join(","));
globs.push_str("}/**");

That pattern also matches .../node_modules/react-focus-lock/dist/es2015/sidecar.js.

2. That glob short-circuits before the package's own sideEffects is consulted.

// turbopack/crates/turbopack-ecmascript/src/chunk/placeable.rs
// fn get_side_effect_free_declaration
if let Some(side_effect_free_packages) = side_effect_free_packages
    && side_effect_free_packages.await?.matches(&path.path)
{
    return Ok(SideEffectsDeclaration::SideEffectFree.cell()); // <-- returns here
}

// ...only reached if the glob did NOT match: read package.json `sideEffects`
//    (the SideEffectsValue::Glob arm below would correctly return
//     SideEffectful for a file matching the allowlist)

So for react-focus-lock, whose package.json declares sideEffects: ["**/sidecar.js", "**/index.js"], sidecar.js is marked side-effect-free and tree-shaken — even though the package explicitly marks it side-effectful. sidecar.js's only job is a registration side effect (exportSidecar(mediumSidecar, FocusTrap)), so once it's dropped the medium is never registered and any focus trap throws Sidecar medium not found.

This matches the observed behavior exactly: the module is dropped only when the package is in optimizePackageImports (glob matches → override). Remove it from the list and the glob no longer matches, so the package.json allowlist is honored and the module is retained — which is also why a webpack build (no such override) always works.

Suggested fix

optimizePackageImports should make packages that don't declare sideEffects tree-shakeable, but it must not override an explicit sideEffects allowlist. Consult package.json first and let an explicit side-effectful declaration win; fall back to the optimizePackageImports glob only when the package makes no declaration:

// package.json sideEffects first — an explicit declaration wins
if let FindContextFileResult::Found(package_json, _) = &*find_package_json {
    match *side_effects_from_package_json(package_json.clone()).await? {
        SideEffectsValue::None => {}                    // no declaration -> fall through
        SideEffectsValue::Constant(b) =>
            return Ok(if b { SideEffectful } else { SideEffectFree }.cell()),
        SideEffectsValue::Glob(glob) => { /* rel_path match -> SideEffectful / SideEffectFree */ }
    }
}
// blanket optimizePackageImports glob only when package.json is silent
if let Some(pkgs) = side_effect_free_packages
    && pkgs.await?.matches(&path.path)
{
    return Ok(SideEffectsDeclaration::SideEffectFree.cell());
}
Ok(SideEffectsDeclaration::None.cell())

This keeps the optimization's benefit (packages with no sideEffects field stay tree-shakeable) while never dropping a module a package explicitly marks side-effectful — matching webpack.