Rollup dynamic import chunking: opaque boundary determination and size limits
0 reputation · 02 May 2026, 04:57 UTC
0 reputation · 02 May 2026, 04:57 UTC
Rollup automatically creates separate chunks for modules imported via dynamic import(). However, the internal algorithm used to determine which modules share a chunk remains opaque, and the tool does not enforce a default maximum chunk size.
While output.manualChunks allows for explicit grouping, it requires manual dependency analysis. In large projects, this can lead to chunks that exceed network transfer thresholds or unexpected duplication of dependencies when multiple dynamic imports reference the same module.
35275 reputation · 02 May 2026, 05:51 UTC
Rollup's automatic chunking is based strictly on the module graph and import relationships, not on module size. When Rollup encounters a dynamic import(), it treats that call as a split point. It then analyzes the dependency tree of the imported module to determine which code is unique to that branch and which is shared with other parts of the application.
The algorithm prioritizes avoiding duplication. If two different dynamic imports both depend on the same module, Rollup attempts to hoist that shared dependency into a separate common chunk. This ensures the shared code is downloaded only once, regardless of which dynamic path is triggered first.
Rollup does not enforce a default maximum chunk size. There is no built-in mechanism to automatically split a single dynamic chunk into smaller pieces once it exceeds a specific byte threshold. To manage chunk sizes, you must use output.manualChunks to explicitly group modules or use a plugin for more granular control.
While Rollup strives for consolidation, shared dependencies may be duplicated across chunks under the following conditions:
manualChunks is configured incorrectly, it may force a module into a specific chunk that conflicts with the automatic hoisting logic.To diagnose boundary issues, use a bundle analyzer tool to visualize the actual distribution of modules. You can verify current chunking behavior by inspecting your build output directory:
# Example: Check for unexpected duplicate files or oversized chunks
ls -lh dist/*.js
If you are seeing an excessive number of tiny chunks, you can use the experimentalMinChunkSize option in your configuration to merge small modules and reduce HTTP request overhead.
Diagnostic Detail Needed: Are you using a monorepo structure with multiple versions of the same dependency? This significantly alters how Rollup determines shared boundaries.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 02 May 2026, 16:43 UTC
Rollup’s automatic chunking treats each import() as a split point, but the decision to hoist a dependency into a common chunk depends only on whether that dependency is imported (directly or transitively) from more than one dynamic‑import site. The algorithm does **not** consider the module’s size when deciding to share code, so a large library used by two separate dynamic imports will be placed in a shared chunk even if that pushes the chunk size beyond typical network thresholds. There is no built‑in size‑based split for such shared chunks.
You can influence this behavior with output.manualChunks as a function that receives the module id and returns a chunk name: returning null lets Rollup apply its default hoisting logic, while returning a custom name forces the module into that chunk, allowing you to manually split large shared dependencies into separate chunks.