Which splitChunks settings keep chunk filenames stable across dependency updates in webpack 5?

Direct Answer

No splitChunks setting alone guarantees stable chunk names when dependency versions change the module graph. The only reliable way to keep filenames stable for caching is to include [contenthash] (or [chunkhash]) in output.filename. A fixed name in a cacheGroup keeps the chunk's name constant, but if the chunk's module composition changes, its content hash changes — producing a new filename. The collision risk you describe (an old file being overwritten) only occurs when [name] is used without a content hash.

What Actually Works for Long-Term Caching

• Default deterministic IDs: Webpack 5 production mode sets optimization.chunkIds: 'deterministic' and optimization.moduleIds: 'deterministic'. These stabilize the numeric IDs and module hashes that feed into chunk content hashes.
• Content-hashed filenames: Use output.filename: '[name].[contenthash].js' (and chunkFilename for async chunks). The filename changes only when the chunk's actual content changes.
• Limit extraction scope: Keep splitChunks.chunks: 'async' (the default) instead of 'all'. Extracting only dynamic imports reduces churn when dependency updates shift module sizes or paths.
• Avoid enforce: true: It bypasses minSize/minChunks thresholds, making chunk composition depend solely on graph topology — highly sensitive to version changes.

What a Fixed cacheGroup.name Does (and Doesn't)

Setting cacheGroups: { vendor: { name: 'vendor', test: /node_modules/, chunks: 'async' } } forces the vendor chunk to always be named vendor. This prevents the name from being auto-generated (e.g., vendors-node_modules_lodash_... ) and shifting between builds. However:

• If a dependency update adds/removes modules that match the test, the chunk's content changes → new [contenthash] → new filename (correct cache invalidation).
• If you omit [contenthash] and rely on [name] alone, a shifting auto-generated name or a fixed name that now contains different modules will write to the same output path, overwriting the old file — the collision you're worried about.
• Multiple cacheGroups with the same fixed name cause build errors; webpack requires unique chunk names.

Recommended Baseline Configuration

module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'async',           // default; limits extraction to dynamic imports
      cacheGroups: {
        vendor: {
          name: 'vendor',        // stable name for readability/debugging
          test: /[\\/]node_modules[\\/]/,
          priority: -10
        }
      }
    }
  },
  output: {
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].js'
  }
};

Verification Steps

1. Run a production build with a pinned dependency (e.g., lodash@4.17.21). Record the vendor chunk filename (e.g., vendor.a1b2c3.js).
2. Upgrade the dependency (lodash@4.17.22), rebuild, and compare:
   • If only the hash changed → content changed, cache invalidation works.
   • If the name changed (e.g., vendor → vendors-xyz) → a cacheGroup lacks a fixed name or chunks: 'all' reshuffled modules.
3. Confirm optimization.chunkIds and moduleIds are 'deterministic' via webpack --json | jq '.optimization.chunkIds'.

One Diagnostic Detail

Are you using output.filename: '[name].js' (no hash) for any entry or chunk, or relying on a service worker / CDN that keys cache entries by [name] alone? If yes, the fixed name helps but content changes will still overwrite the same URL — add [contenthash] to the filename pattern.