Turbopack should not load both of these as separate live implementations in the same server graph: - `dist/emotion-react.cjs.js` - `dist/emotion-react.development.esm.js` Webpack does not hit that split because `dist/emotion-react.cjs.mjs` is only a thin ESM re-export of `dist/emotion-react.cjs.js`.

nextjs - ✅(Solved) Fix Turbopack resolves @emotion/react to both CJS and ESM builds in the same server graph, causing hydration [1 pull requests, 6 comments, 3 participants]

nextjs2026-03-15 11:12:40

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

vercel/next.js#91411•Fetched 2026-04-08 02:02:05

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×6subscribed ×5mentioned ×4cross-referenced ×2

Error Message

Open console, see hydration error. Run again with pnpm run dev-webpack, no hydration error.

Root Cause

Webpack does not hit that split because dist/emotion-react.cjs.mjs is only a thin ESM re-export of dist/emotion-react.cjs.js.

Fix Action

Fixed

Fixed by PR: fix(resolve): match first successful condition in conditional exports (https://github.com/vercel/next.js/pull/91417)

PR fix notes

PR #91417: fix(resolve): match first successful condition in conditional exports

Repository: vercel/next.js
Author: Abmarne
State: closed | merged: False
Link: https://github.com/vercel/next.js/pull/91417

Description (problem / solution / changelog)

Turbopack Dual-Module Hydration Error Fix: #91411

Problem Description

Turbopack was incorrectly resolving conditional exports in package.json files, causing dual-module hydration errors. When packages like @emotion/react exposed multiple conditional export targets, Turbopack would load both the CJS and ESM versions in the same server graph, while Webpack correctly loaded only one.

Reproduction Case

Repository: https://github.com/garronej/turbopack-emotion-dual-module
Issue: Hydration error when running with pnpm run dev-turbopack
Expected: No error (matches Webpack behavior)

Root Cause

When @emotion/react exposes these conditional exports:

{
  "exports": {
    ".": {
      "default": "dist/emotion-react.cjs.js",
      "import": "dist/emotion-react.cjs.mjs",
      "development.module": "dist/emotion-react.development.esm.js"
    }
  }
}

Webpack behavior (correct):

Loads only ONE implementation (e.g., dist/emotion-react.cjs.js)
Treats .cjs.mjs as a re-export of the CJS file

Turbopack behavior (buggy - BEFORE FIX):

Loads BOTH dist/emotion-react.cjs.js AND dist/emotion-react.development.esm.js
Creates dual-module situation where React context exists in two different module instances
Causes hydration errors because server and client have different module graphs

Changes Made

File Modified

Path: turbopack/crates/turbopack-core/src/resolve/remap.rs

Functions Fixed

Two functions had the same bug pattern and were both fixed:

SubpathValue::add_results (lines 145-186)
ReplacedSubpathValue::add_results (lines 273-320)

Detailed Code Changes

Change 1: SubpathValue::add_results (lines 145-186)

BEFORE (Buggy Code):

SubpathValue::Conditional(list) => {
    for (condition, value) in list {
        let condition_value = if condition == "default" {
            &ConditionValue::Set
        } else {
            condition_overrides
                .get(condition.as_str())
                .or_else(|| conditions.get(condition))
                .unwrap_or(unspecified_condition)
        };
        match condition_value {
            ConditionValue::Set => {
                if value.add_results(...) {
                    return true;
                }
            }
            ConditionValue::Unset => {}
            ConditionValue::Unknown => {
                condition_overrides.insert(condition, ConditionValue::Set);
                if value.add_results(...) {
                    condition_overrides.insert(condition, ConditionValue::Unset); // ❌ BUG: Continues trying!
                } else {
                    condition_overrides.remove(condition.as_str());
                }
            }
        }
    }
    false
}

AFTER (Fixed Code):

SubpathValue::Conditional(list) => {
    // Process conditions in order and return immediately on first successful match.
    // This matches Node.js conditional exports behavior where the first matching
    // condition wins, preventing dual-module issues.
    for (condition, value) in list {
        let condition_value = if condition == "default" {
            &ConditionValue::Set
        } else {
            condition_overrides
                .get(condition.as_str())
                .or_else(|| conditions.get(condition))
                .unwrap_or(unspecified_condition)
        };
        match condition_value {
            ConditionValue::Set => {
                if value.add_results(...) {
                    return true;
                }
            }
            ConditionValue::Unset => {}
            ConditionValue::Unknown => {
                condition_overrides.insert(condition, ConditionValue::Set);
                if value.add_results(...) {
                    // ✅ FIX: Found a match with this condition set - return immediately
                    return true;
                }
                // ✅ FIX: Backtrack: this condition didn't work, remove it and continue
                condition_overrides.remove(condition.as_str());
            }
        }
    }
    false
}

Change 2: ReplacedSubpathValue::add_results (lines 273-320)

BEFORE (Buggy Code):

ReplacedSubpathValue::Conditional(list) => {
    for (condition, value) in list {
        let condition_value = if condition == "default" {
            &ConditionValue::Set
        } else {
            condition_overrides
                .get(condition.as_str())
                .or_else(|| conditions.get(&condition))
                .unwrap_or(unspecified_condition)
        };
        match condition_value {
            ConditionValue::Set => {
                if value.add_results(...) {
                    return true;
                }
            }
            ConditionValue::Unset => {}
            ConditionValue::Unknown => {
                condition_overrides.insert(condition.clone(), ConditionValue::Set);
                if value.add_results(...) {
                    condition_overrides.insert(condition, ConditionValue::Unset); // ❌ BUG: Continues trying!
                } else {
                    condition_overrides.remove(condition.as_str());
                }
            }
        }
    }
    false
}

AFTER (Fixed Code):

ReplacedSubpathValue::Conditional(list) => {
    // Process conditions in order and return immediately on first successful match.
    // This matches Node.js conditional exports behavior where the first matching
    // condition wins, preventing dual-module issues.
    for (condition, value) in list {
        let condition_value = if condition == "default" {
            &ConditionValue::Set
        } else {
            condition_overrides
                .get(condition.as_str())
                .or_else(|| conditions.get(&condition))
                .unwrap_or(unspecified_condition)
        };
        match condition_value {
            ConditionValue::Set => {
                if value.add_results(...) {
                    return true;
                }
            }
            ConditionValue::Unset => {}
            ConditionValue::Unknown => {
                condition_overrides.insert(condition.clone(), ConditionValue::Set);
                if value.add_results(...) {
                    // ✅ FIX: Found a match with this condition set - return immediately
                    return true;
                }
                // ✅ FIX: Backtrack: this condition didn't work, remove it and continue
                condition_overrides.remove(condition.as_str());
            }
        }
    }
    false
}

Technical Explanation

The Bug Pattern

The buggy code followed this flawed logic when encountering an Unknown condition:

Try with condition set to Set → finds first matching module ✅
Insert Unset and continue → tries alternative path ❌
If that fails, remove the condition → continues loop
Result: Multiple modules get accumulated in the target vector

This is similar to validation error accumulation bugs where all errors are collected instead of stopping at the first failure.

The Fix Logic

The fixed code implements short-circuit evaluation:

Try with condition set to Set → finds first matching module ✅
Return immediately → no further exploration ✅
Only backtrack if resolution fails completely
Result: Single module resolution, matching Node.js spec

Why This Matches Node.js Behavior

According to Node.js Conditional Exports specification:

Conditions are evaluated in order and the first match wins.

The fix ensures Turbopack:

Evaluates conditions sequentially
Stops at the first successful resolution
Doesn't accumulate alternative matches
Produces deterministic, single-module results

Impact

Before Fix

Turbopack console output (BUGGY):
tss-react CJS
@emotion/react loaded: dist/emotion-react.cjs.js
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.cjs.js
tss-react/next/pagesDir CJS
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.development.esm.js  ❌
@emotion/react loaded: dist/emotion-react.development.esm.js  ❌ DUAL MODULE!
tss-react/mui CJS

Result: Hydration error ❌

After Fix

Turbopack console output (FIXED):
tss-react CJS
@emotion/react loaded: dist/emotion-react.cjs.js
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.cjs.js
tss-react/next/pagesDir CJS
@emotion/react loaded: dist/emotion-react.cjs.mjs  ✅ SINGLE MODULE
tss-react/mui CJS

Result: No hydration error ✅

Testing Strategy

Manual Testing

Clone reproduction repo:

git clone https://github.com/garronej/turbopack-emotion-dual-module
cd turbopack-emotion-dual-module
pnpm install

Build Next.js with fix:

cd /path/to/next.js
# Install Rust toolchain first if not already installed
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Build Rust code
cargo build --release

# Build Next.js
pnpm install
pnpm build-all

Test with Turbopack:

cd turbopack-emotion-dual-module
pnpm run dev-turbopack

Verify:
- ✅ No hydration errors in console
- ✅ Only one @emotion/react module loaded
- ✅ Application renders correctly
Compare with Webpack:
```
pnpm run dev-webpack
```
Output should match Turbopack's fixed behavior

Automated Testing

To add automated tests, create test cases in: turbopack/crates/turbopack-core/src/resolve/mod.rs#tests

Example test structure:

#[tokio::test]
async fn test_conditional_exports_single_resolution() {
    // Test that conditional exports resolve to single module
    // Verify no dual-module accumulation occurs
}

Build Instructions

Prerequisites

Install Rust toolchain:

# Linux/macOS
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Windows: Download from https://rustup.rs/

Install Node.js dependencies:
```
cd /path/to/next.js
pnpm install
```

Build Commands

# Build Rust code (from workspace root)
cargo build --release

# Or build specific crate
cd turbopack/crates/turbopack-core
cargo build --release

# Build Next.js package
pnpm --filter=next build

# Full build (Rust + JavaScript)
pnpm build-all

Development Mode

For faster iteration during development:

# Watch mode for Rust (auto-rebuilds on changes)
cargo watch -x build

# Dev mode for Next.js
pnpm --filter=next dev

Related Issues

GitHub Issue: garronej/tss-react#231
Root Cause: Similar to "static variable accumulation" bugs in Java services
Pattern: Short-circuit evaluation vs. accumulation anti-pattern

References

Author

Fix implemented based on analysis of Turbopack's conditional export resolution logic in turbopack-core/src/resolve/remap.rs.

Status: ✅ Code changes complete, ready for build and testing

Next Steps:

Build Rust code with cargo build
Build Next.js with pnpm build-all
Test with reproduction case
Run existing test suite to verify no regressions
Submit PR to Next.js repository

Changed files

turbopack/crates/turbopack-core/src/resolve/remap.rs (modified, +14/-6)

Code Example

git clone https://github.com/garronej/turbopack-emotion-dual-module
cd turbopack-emotion-dual-module
pnpm install
pnpm run dev-turbopack

---

tss-react CJS
@emotion/react loaded: dist/emotion-react.cjs.js
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.cjs.js
tss-react/next/pagesDir CJS
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.development.esm.js
@emotion/react loaded: dist/emotion-react.development.esm.js
tss-react/mui CJS

---

tss-react CJS
@emotion/react loaded: dist/emotion-react.cjs.js
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.cjs.js
tss-react/next/pagesDir CJS
@emotion/react loaded: dist/emotion-react.cjs.mjs
tss-react/mui CJS

---

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.0.0: Wed Sep 17 21:35:32 PDT 2025; root:xnu-12377.1.9~141/RELEASE_ARM64_T6020
  Available memory (MB): 65536
  Available CPU cores: 12
Binaries:
  Node: 22.12.0
  npm: 11.4.1
  Yarn: 1.22.22
  pnpm: 10.13.1
Relevant Packages:
  next: 16.2.0-canary.99 // Latest available version is detected (16.2.0-canary.99).
  eslint-config-next: 15.5.7
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

RAW_BUFFERClick to expand / collapse

Hello dear Next maintainers,

Link to the code that reproduces this issue

https://github.com/garronej/turbopack-emotion-dual-module

To Reproduce

git clone https://github.com/garronej/turbopack-emotion-dual-module
cd turbopack-emotion-dual-module
pnpm install
pnpm run dev-turbopack

Open console, see hydration error.

Run again with pnpm run dev-webpack, no hydration error.

Current vs. Expected behavior

Observed logs

Turbopack:

tss-react CJS
@emotion/react loaded: dist/emotion-react.cjs.js
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.cjs.js
tss-react/next/pagesDir CJS
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.development.esm.js
@emotion/react loaded: dist/emotion-react.development.esm.js
tss-react/mui CJS

Webpack:

tss-react CJS
@emotion/react loaded: dist/emotion-react.cjs.js
@emotion/react loaded: _isolated-hnrs/dist/emotion-react-_isolated-hnrs.cjs.js
tss-react/next/pagesDir CJS
@emotion/react loaded: dist/emotion-react.cjs.mjs
tss-react/mui CJS

Expected behavior

Turbopack should not load both of these as separate live implementations in the same server graph:

dist/emotion-react.cjs.js
dist/emotion-react.development.esm.js

Webpack does not hit that split because dist/emotion-react.cjs.mjs is only a thin ESM re-export of dist/emotion-react.cjs.js.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.0.0: Wed Sep 17 21:35:32 PDT 2025; root:xnu-12377.1.9~141/RELEASE_ARM64_T6020
  Available memory (MB): 65536
  Available CPU cores: 12
Binaries:
  Node: 22.12.0
  npm: 11.4.1
  Yarn: 1.22.22
  pnpm: 10.13.1
Relevant Packages:
  next: 16.2.0-canary.99 // Latest available version is detected (16.2.0-canary.99).
  eslint-config-next: 15.5.7
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

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

Turbopack

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

next dev (local)

Additional context

Why this looks like a Turbopack bug

@emotion/react exposes distinct conditional export targets for:

default -> dist/emotion-react.cjs.js
import -> dist/emotion-react.cjs.mjs
development.module -> dist/emotion-react.development.esm.js

Turbopack appears to resolve both the CJS target and the separate development ESM target in one server render path. That creates a dual-module situation and leads to hydration / SSR issues.

Additional context

The repro uses tss-react/next/pagesDir, but the suspected root cause is not tss-react itself. The relevant signal is that Turbopack resolves @emotion/react to both the CJS implementation and a separate development ESM implementation in the same graph, while webpack effectively collapses to a single implementation.

Ref: https://github.com/garronej/tss-react/issues/231

extent analysis

TL;DR

The most likely fix is to configure Turbopack to resolve @emotion/react to a single implementation, similar to how Webpack collapses to a single implementation.

Guidance

Investigate Turbopack's resolution algorithm to understand why it loads both dist/emotion-react.cjs.js and dist/emotion-react.development.esm.js as separate implementations.
Consider configuring Turbopack to use a single implementation for @emotion/react, potentially by using an alias or a custom resolution rule.
Review the @emotion/react package exports to understand the conditional export targets and how they are being resolved by Turbopack.
Compare the Turbopack configuration with the Webpack configuration to identify any differences that may be contributing to the issue.

Notes

The issue appears to be specific to Turbopack and its resolution algorithm, and may require a custom configuration or workaround to resolve.

Recommendation

Apply a workaround to configure Turbopack to resolve @emotion/react to a single implementation, as the root cause of the issue is likely related to Turbopack's resolution algorithm.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

Turbopack should not load both of these as separate live implementations in the same server graph:

dist/emotion-react.cjs.js
dist/emotion-react.development.esm.js

Webpack does not hit that split because dist/emotion-react.cjs.mjs is only a thin ESM re-export of dist/emotion-react.cjs.js.

#ssr #cache issue #memory leak #API versioning #request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

nextjs - ✅(Solved) Fix Turbopack resolves @emotion/react to both CJS and ESM builds in the same server graph, causing hydration [1 pull requests, 6 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fixed

PR fix notes

PR #91417: fix(resolve): match first successful condition in conditional exports

Description (problem / solution / changelog)

Turbopack Dual-Module Hydration Error Fix: #91411

Problem Description

Reproduction Case

Root Cause

Changes Made

File Modified

Functions Fixed

Detailed Code Changes

Change 1: SubpathValue::add_results (lines 145-186)

Change 2: ReplacedSubpathValue::add_results (lines 273-320)

Technical Explanation

The Bug Pattern

The Fix Logic

Why This Matches Node.js Behavior

Impact

Before Fix

After Fix

Testing Strategy

Manual Testing

Automated Testing

Build Instructions

Prerequisites

Build Commands

Development Mode

Related Issues

References

Author

Changed files

Code Example

Link to the code that reproduces this issue

To Reproduce

Current vs. Expected behavior

Observed logs

Expected behavior

Provide environment information

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

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

Additional context

Why this looks like a Turbopack bug

Additional context

extent analysis

TL;DR

Guidance

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING