Webpack 4长期缓存配置问题：从CommonsChunkPlugin迁移至SplitChunks遇阻

Hey there! I’ve helped a lot of folks migrate from CommonsChunkPlugin to Webpack 4’s splitChunks for long-term caching, so let’s walk through the fixes step by step. Here’s how to get your caching working reliably:

1. Replace CommonsChunkPlugin with splitChunks #

Webpack 4’s built-in splitChunks is way more powerful than the old plugin. The key here is using contenthash in filenames to ensure only changed files get new hashes. Add this to your optimization section:

module.exports = {
  // ... rest of your config
  optimization: {
    splitChunks: {
      chunks: 'all', // Split both sync and async chunks
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          filename: 'js/[name].[contenthash:8].js', // Content-based hash for caching
          priority: -10 // Prioritize vendor chunk over common
        },
        common: {
          name: 'common',
          filename: 'js/[name].[contenthash:8].js',
          minChunks: 2, // Split code used in at least 2 modules
          priority: -20,
          reuseExistingChunk: true // Reuse existing chunks instead of creating new ones
        }
      }
    },
    // ... more optimization settings below
  }
};

2. Extract Runtime Code Separately #

Webpack’s runtime code handles module mapping, and it can change even if your actual code doesn’t. Split it into its own chunk to avoid busting the cache for other files:

optimization: {
  // ... splitChunks config above
  runtimeChunk: {
    name: 'runtime' // Generates runtime.[contenthash].js
  }
}

3. Stabilize Module IDs with HashedModuleIdsPlugin #

You already imported this plugin—make sure it’s enabled in your plugins array. This ensures module IDs don’t change when you add/remove files, which keeps your cache consistent:

plugins: [
  new HashedModuleIdsPlugin({
    hashFunction: 'sha256',
    hashDigest: 'hex',
    hashDigestLength: 8 // Short, unique hash
  }),
  // ... other plugins like MiniCssExtractPlugin
]

4. Cache CSS Files with MiniCssExtractPlugin #

Since you’re using this plugin to extract CSS, add contenthash to its filenames too:

plugins: [
  new MiniCssExtractPlugin({
    filename: 'css/[name].[contenthash:8].css',
    chunkFilename: 'css/[id].[contenthash:8].css'
  }),
  // ... other plugins
]

5. Optional: Cache UglifyJS Builds #

Speed up subsequent builds by enabling caching in UglifyJsPlugin:

optimization: {
  minimizer: [
    new UglifyJsPlugin({
      cache: true, // Cache minified results
      parallel: true, // Use multi-core processing
      sourceMap: false // Disable if you don't need source maps
    })
  ]
}

• Update your output filenames: Make sure your main entry files use contenthash too:

  output: {
    filename: 'js/[name].[contenthash:8].js',
    chunkFilename: 'js/[id].[contenthash:8].js',
    path: path.resolve(__dirname, 'dist')
  }
  

• Avoid dynamic import variables: If you use import() with dynamic paths like import(./${file}.js), Webpack can’t generate stable hashes. Use static paths or magic comments (like /* webpackChunkName: "my-chunk" */) instead.
• Test the cache: After making changes to your business code, check that only the affected chunk’s hash changes—vendors, common, and runtime chunks should keep their hashes.

内容的提问来源于stack exchange，提问作者javauser35