Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix Next 16.1 showing 404 errors for dynamic imported components [TURBOPACK] [1 pull requests, 6 comments, 4 participants]

Official PRs (…)
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.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#87680•Fetched 2026-04-08 02:06:40
View on GitHub
Comments
6
Participants
4
Timeline
25
Reactions
2
Author
dcheng1290dcheng1290
Participants
dcheng1290dcheng1290github-actions[bot]github-actions[bot]lukesandberglukesandbergmischnicmischnic
Timeline (top)
commented ×6subscribed ×5labeled ×4mentioned ×3

Error Message

https://github.com/dcheng1290/next-dynamic-error/tree/main turbopack: I wasn't expect any 404 errors due to nested dynamic imports and I was not getting this error in 16.0.10.

Fix Action

Fixed

PR fix notes

PR #88775: Fix react-loadable-manifest chunk hash mismatch by preserving async loader mapping

Description (problem / solution / changelog)

What?

Fixes a bug where react-loadable-manifest.json in Turbopack dev mode contained references to chunk files with wrong hashes, causing 404 errors when loading dynamic imports.

Why?

When using next/dynamic with nested imports (e.g., a dynamic component that itself imports other modules), the chunk files referenced in react-loadable-manifest.json had different hashes than the actual generated chunk files.

The root cause was that collect_next_dynamic_chunks was recomputing chunk content that was already computed by make_chunk_group. This pattern was inherently brittle because Next.js code had to carefully mirror Turbopack's internal chunking logic to get consistent hashes.

This brittleness was exposed when the turbopackClientSideNestedAsyncChunking feature was disabled in dev mode (released in 16.1). The subtle differences in how availability info was computed led to hash mismatches.

How?

Instead of recomputing chunks for next/dynamic imports, this PR preserves the module→async loader mapping from when chunks are first computed in make_chunk_group, and looks up pre-computed chunks directly. This eliminates the need for Next.js to replicate Turbopack's chunking logic.

Key changes:

  1. Extended MakeChunkGroupResult and ChunkGroupResult with async_loaders_by_module field

    • Maps ResolvedVc<Box<dyn ChunkableModule>> → ResolvedVc<Box<dyn ChunkItem>>
    • Preserves the module→loader relationship computed during chunking

  2. Eliminated redundancy in MakeChunkGroupResult

    • Removed the separate references field (was just upcasted async loaders)
    • Added references() method that derives references on-demand from the map

  3. Simplified collect_next_dynamic_chunks

    • Now performs simple lookup instead of recomputation
    • Removed module_graph and chunking_context parameters
    • Uses NextDynamicChunkAvailability enum to access pre-computed chunk groups

  4. Added regression test to verify chunk files referenced in manifest exist

Files modified:

  • turbopack/crates/turbopack-core/src/chunk/chunk_group.rs - Add mapping, remove redundant field
  • turbopack/crates/turbopack-core/src/chunk/chunking_context.rs - Extend ChunkGroupResult
  • turbopack/crates/turbopack-browser/src/chunking_context.rs - Pass through mapping
  • turbopack/crates/turbopack-nodejs/src/chunking_context.rs - Pass through mapping
  • crates/next-api/src/dynamic_imports.rs - Lookup instead of recompute
  • crates/next-api/src/pages.rs - Updated caller
  • crates/next-api/src/app.rs - Updated caller
  • crates/next-core/src/next_app/app_client_references_chunks.rs - Initialize empty map

Fixes #87680

Changed files

  • crates/next-api/src/app.rs (modified, +0/-4)
  • crates/next-api/src/dynamic_imports.rs (modified, +35/-22)
  • crates/next-api/src/pages.rs (modified, +12/-17)
  • crates/next-core/src/next_app/app_client_references_chunks.rs (modified, +1/-1)
  • test/development/nested-dynamic-components/components/FeatureCard.tsx (added, +23/-0)
  • test/development/nested-dynamic-components/components/UserProfile.tsx (added, +20/-0)
  • test/development/nested-dynamic-components/components/nested/NestedBadge.tsx (added, +3/-0)
  • test/development/nested-dynamic-components/components/nested/NestedIcon.tsx (added, +3/-0)
  • test/development/nested-dynamic-components/components/nested/NestedStats.tsx (added, +3/-0)
  • test/development/nested-dynamic-components/nested-dynamic-components.test.ts (added, +58/-0)
  • test/development/nested-dynamic-components/pages/index.tsx (added, +22/-0)
  • turbopack/crates/turbopack-browser/src/chunking_context.rs (modified, +11/-23)
  • turbopack/crates/turbopack-core/src/chunk/chunk_group.rs (modified, +34/-9)
  • turbopack/crates/turbopack-core/src/chunk/chunking_context.rs (modified, +39/-24)
  • turbopack/crates/turbopack-nodejs/src/chunking_context.rs (modified, +11/-20)

Code Example

node 22.17
next 16.1.0
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/dcheng1290/next-dynamic-error/tree/main

To Reproduce

  1. npm run dev:turbo
  2. keep network request tab opened
  3. go to http://localhost:3000/test
  4. observe 404 errors in network request tab

Current vs. Expected behavior

turbopack: I wasn't expect any 404 errors due to nested dynamic imports and I was not getting this error in 16.0.10.

Provide environment information

node 22.17
next 16.1.0

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

Lazy Loading

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

next dev (local)

Additional context

I am running into 404 errors locally in my app after updating to 16.1 potentially due to nested dynamic imports. This only happens when running turbopack and it doesn't happen with webpack.

extent analysis

TL;DR

Downgrade to Next.js version 16.0.10 to potentially resolve the 404 errors caused by nested dynamic imports with Turbopack.

Guidance

  • Verify that the issue is indeed caused by the upgrade to Next.js 16.1.0 by checking the release notes for any changes related to Turbopack and dynamic imports.
  • Test the application with Webpack instead of Turbopack to confirm that the issue is specific to Turbopack.
  • Check the network request tab for any patterns or clues about the missing resources that are causing the 404 errors.
  • Consider opening an issue with the Next.js team or seeking help from the community if downgrading is not a viable long-term solution.

Notes

The provided information suggests that the issue is specific to Next.js 16.1.0 and Turbopack, but without further investigation, it's unclear what changes in the new version are causing the problem.

Recommendation

Apply workaround: Downgrade to Next.js 16.0.10, as it is known to work without this issue, and wait for a potential fix in a future version of Next.js.

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?
Loading…
#model download#tokenizer error#prompt formatting#chain error#conversation history

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

nextjs - ✅(Solved) Fix Next 16.1 showing 404 errors for dynamic imported components [TURBOPACK] [1 pull requests, 6 comments, 4 participants]