Hydration error when using Turbopack with dynamically imported named exports.

[gurkerl83]

Link to the code that reproduces this issue

https://github.com/gurkerl83/next-turbo-dynamic-import

To Reproduce

1. Clone the reproduction repository:

git clone https://github.com/gurkerl83/next-turbo-dynamic-import.git

2. Install dependencies using pnpm:

pnpm install

3. Run the development server with Turbopack:

pnpm dev:turbo

4. Observe the console for hydration issues.

Current vs. Expected behavior

Current Behavior:

• Webpack (pnpm dev): The application runs without issues, and both dynamically imported components (direct import and named export import) render as expected.
• Turbopack (pnpm dev:turbo): The component that uses a named export (module.SimpleComponent) results in a hydration error. The browser console shows a hydration mismatch between the server-rendered HTML and the client-side React tree.

Expected Behavior:

• The components should hydrate correctly with both Webpack and Turbopack.
• No hydration errors should occur when using dynamically imported named exports.

Examples:

1. Works with both Webpack and Turbopack (direct file path import)

const ComponentDirectImport = dynamic(
  () => import("@module/first/src/SimpleComponent")
);

2. Works with Webpack but causes hydration error with Turbopack (dynamic import with named export)

const ComponentNamedImportWithIssue = dynamic(() =>
  import("@module/first").then((module) => module.SimpleComponent)
);

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:17:33 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6031
  Available memory (MB): 65536
  Available CPU cores: 16
Binaries:
  Node: 22.6.0
  npm: 10.8.2
  Yarn: N/A
  pnpm: 9.11.0
Relevant Packages:
  next: 15.0.0-canary.177 // Latest available version is detected (15.0.0-canary.177).
  react: 19.0.0-rc-0751fac7-20241002
  react-dom: 19.0.0-rc-0751fac7-20241002
  typescript: 5.6.2
Next.js Config:
  output: N/A

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

Lazy Loading, Pages Router, Turbopack

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

next dev (local)

Additional context

• The hydration error occurs only when using Turbopack with dynamically imported named exports.
• The problem is triggered when using .then() after a dynamic import to access a named export (import("@module/first").then((module) => module.SimpleComponent)).
• The project uses React's latest release candidate version (19.0.0-rc-0751fac7-20241002) and Next.js's latest canary version (15.0.0-canary.177).
• I tested the application against the latest canary release, also against previous versions.
• Direct imports do not cause the same issue, which suggests that the problem is related specifically to the way Turbopack handles named exports within dynamic imports.

[devjiwonchoi]

Hi @gurkerl83, I'm here to check in, does it work when using as { default: module.SimpleComponent }?

[gurkerl83]

@devjiwonchoi I will try with the latest canary version later today, and keep you updated.

[gurkerl83]

@devjiwonchoi I tried with the latest canary versions of both next and react. I have updated the reproducer with these versions.

 "next": "15.0.0-canary.196",
 "react": "19.0.0-rc-77b637d6-20241016",
 "react-dom": "19.0.0-rc-77b637d6-20241016"

Putting it on default when importing like the following, also fails with the canary versions mentioned.

const ComponentNamedImportWithIssue = dynamic(() =>
  import("@module/first").then((module) => ({
    default: module.SimpleComponent,
  }))
);

The closest I could find in the set of open PRs, which maybe is related is, but this is just a guess. #71145

Can you please forward this issue to one of the engineers, who are working on the turbopack feature.

Thx!

[Susheel4115]

Hi @gurkerl83 ,
I can see the same error in the web page

The above error in the screenshot is related to your issue?please let me know.

[qasimgit]

@devjiwonchoi @gurkerl83 I am also getting this hydration error, not sure if this is related to this thread, just created new project using latest nextjs version with turbopack

[Susheel4115]

Moreover I can see the error on initial page load once we refresh the page the error has gone!
ss:

[timneutkens]

@Susheel4115 @qasimgit I'd recommend opening another issue because these don't look related based on the screenshot. It looks like you just have a generic hydration error caused by e.g. a chrome extension installed in your browser.

Please make sure that when posting comments you're not sharing screenshots but instead share the actual code. A great example of a good and useful interaction is @gurkerl83's investigating and providing a reproduction in this issue.

[Susheel4115]

@timneutkens even though I tried uninstalling concerned extensions it still showing error in the console after the refresh its gone.

[timneutkens]

I'd love to help you but I can't help you if you don't share the code that reproduces the issue 🙂 Please open a new issue 🙏

[gurkerl83]

I tried to make the description as clear as possible.

The hydration error is caused when using these in combination.

• turbopack
• next/dynamic
• named exports from a module

Hydration errors can be caused by many reasons, this particular one is only forming when these conditions are met.

@Susheel4115 I also guess that you have some kind of extension interfering, other reasons might be a secondary react installation in your node modules, but this might be only the case when you are linking libraries by hand after compiling them. Take a fresh browser installation an see if the error persists. The reproducer I provided shows the hydration error even on refresh. Hope this helps.

Thx!

[timneutkens]

@Susheel4115 please read my previous messages, further messages on this issue will be hidden as spam as they're irrelevant for the issue @gurkerl83 reported.

[Susheel4115]

okay @timneutkens

[gurkerl83]

Hi @timneutkens,

It’s been a while! I know there’s a lot happening with Turbopack, but I was wondering if one of the developers might be able to take a look at the issue. I’ve retested this with the latest Canary versions:

"next": "15.0.4-canary.28"
"react": "19.0.0-rc-7670501b-20241124"
"react-dom": "19.0.0-rc-7670501b-20241124"

Unfortunately, the problem persists. The recent changes related to dynamic/import don’t seem to have resolved it yet.

Thanks so much for your help!

[Susheel4115]

Hi @gurkerl83,

Glad to see your message I have cloned the code repo using your provided url and while I try to debug the code I came across this piece of code :

loadableOptions = { ...loadableOptions, ...options }

const loaderFn = loadableOptions.loader as () => LoaderComponent

const loader = () =>
loaderFn != null
? loaderFn().then(convertModule)
: Promise.resolve(convertModule(() => null))

I can understand there is a problem with names export that too in turbopack please check the code I have provided if there is any leads please let me I know I found this issue is interesting 👍🏽

[ryrybeal13]

I'm having the same issue (double rendering) but only when my dynamic component is using the { ssr: true } option.

[gurkerl83]

The problem is fixed in 15.1.1-canary.14, most likely here d3529ba.

Important note:
15.1.1-canary.14 is newer then 15.1.2, so make sure you specify 15.1.1-canary.14 or newer.

[ryrybeal13]

For me, this doesn't resolve the problem. I still have a double-rendered component.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.