rspack-split-chunks

Rspack SplitChunks Optimization

Use this skill when the task is to recommend, review, or debug optimization.splitChunks. If you are using ESM library, it's not the same algorithm of this skill.

Default stance

• Distinguish repo defaults from recommended production baselines.
• Rspack's built-in default is chunks: "async", but for most production web apps the best starting point is:

optimization: {
  splitChunks: {
    chunks: "all",
  },
}

• Keep the default cache groups unless there is a concrete reason to replace them.
• Treat name as a graph-shaping option, not a cosmetic naming option.
• Do not use splitChunks to reason about JavaScript execution order or tree shaking. For JS, chunk loading/execution order is preserved by the runtime dependency graph, and tree shaking is decided elsewhere.

Read references/repo-behavior.md when you need the source-backed rationale.

What To Optimize For

First identify which problem the user actually has:

• duplicated modules across entry or async boundaries
• a route fetching a large shared chunk with mostly unused modules
• too many tiny chunks
• a vendor/common chunk that changes too often and hurts caching
• an oversized async or initial chunk that should be subdivided
• confusion about whether splitChunks affects runtime execution order

Do not optimize all of these at once. Pick the primary goal and keep the rest as constraints.

Workflow

1. Start from the safest production baseline

Unless the user already has a measured problem that requires custom grouping, prefer:

optimization: {
  splitChunks: {
    chunks: "all",
  },
}

Why:

• it lets splitChunks dedupe modules across both initial and async chunks
• it still only loads chunks reachable from the current entry/runtime
• it usually avoids loading unnecessary modules better than hand-written global vendor buckets

If the existing config disables default or defaultVendors, assume that is suspicious until proven necessary.