Automatic chunking vs manualChunks for cache-friendly hashes

Direct Answers

1. Automatic chunking is not sufficient for stable entry-point hashes when shared dependencies change. Any shift in the shared-chunk graph — even a version bump in a transitive dependency — rewrites the entry chunk's content and changes its hash.
2. manualChunks (function form) is the only documented way to guarantee a vendor chunk that never invalidates entry hashes when application code is untouched. The maintenance burden is real but bounded; cycle risk exists but is detectable.
3. experimentalMinChunkSize is not a middle ground for this goal. It only merges chunks below a size threshold; it does not pin vendor modules or prevent reshuffling, so it inherits the same hash-churn behavior as default chunking.

Why Automatic Chunking Churns Hashes

Rollup 4.x's automatic chunking builds a deterministic module graph, but the composition of shared chunks depends on the full dependency topology. When a vendor library updates, the set of modules that qualify as "shared between entry A and entry B" can change. Even if your application code is identical, the generated entry chunk now imports a different shared chunk (or the shared chunk's internal module order changes), so its content hash changes.

Content hashing is purely a function of the generated code bytes. Automatic chunking maximizes granularity, which maximizes sensitivity to graph changes.

Why manualChunks Function Form Works

A function like the following isolates all node_modules into a single, stable chunk:

output: {
  manualChunks(id) {
    if (id.includes('node_modules')) return 'vendor';
  },
  chunkFileNames: 'assets/[name]-[hash].js'
}

Because the vendor chunk's module set is fixed by the function, its hash only changes when a vendor file's content changes. Entry chunks import the vendor chunk by stable name, so their hashes remain stable across application-only edits.

Maintenance & Cycle Risk

• Maintenance: You must update the function when you add new top-level vendor dependencies that should stay in the vendor chunk, or when you want to split vendor code further (e.g., separate react-vendor from utils-vendor). This is typically a few lines per quarter.
• Cycles: If the function assigns modules such that chunk A imports chunk B and chunk B imports chunk A, Rollup 4.x emits a warning and falls back to automatic chunking for the cycle. This silently defeats stability. Avoid cycles by keeping the vendor chunk as a leaf (no imports back into it) and by not creating feature chunks that import each other circularly.

Verification Steps

1. Create a minimal repo with two ES entries that dynamically import the same vendor library.
2. Build with default chunking, record entry chunk hashes from --manifest.
3. Bump the vendor version (or add a dummy export), rebuild, and observe hash changes.
4. Switch to the manualChunks function above, repeat steps 2–3. Entry hashes should stay identical.
5. Run with experimentalMinChunkSize: 10000 and confirm entry hashes still churn.

One Diagnostic Detail

Do your entry points share only third-party code, or do they also share first-party modules that you intend to keep in a separate "shared app" chunk? If the latter, you'll need a second manualChunks rule (e.g., if (id.startsWith('src/shared/')) return 'shared-app';) and must verify no cycles form between vendor, shared-app, and the entries.