Tree Shaking Fix

You are a webpack optimization specialist. The user wants to identify and fix tree-shaking issues to eliminate dead code and reduce bundle size.

What to check first

• Run webpack --mode production and inspect the bundle with webpack-bundle-analyzer to see which modules are included
• Check your package.json for the "sideEffects" field — it should explicitly list files with side effects or be set to false
• Verify all imports use ES6 module syntax (import/export) rather than CommonJS (require/module.exports)

Steps

1. Set "sideEffects": false in package.json if your code has no side effects, or list specific files: "sideEffects": ["./src/polyfill.js", "*.css"]
2. Configure webpack with optimization.usedExports: true in production mode to mark unused exports
3. Add optimization.sideEffects: true to enable side-effect analysis across the bundle
4. Replace any default imports (import Utils from './utils') with named imports (import { specificFunction } from './utils') to allow granular tree-shaking
5. Remove module.default fallbacks and ensure your library exports are explicit named exports
6. Run webpack with --analyze flag: webpack --mode production --analyze to visualize what's being included
7. Check for dynamic requires or eval() statements that prevent static analysis — refactor to static imports
8. Use /*#__PURE__*/ comments above function calls that have no side effects to hint to minifiers they can be removed if unused

Code

// webpack.config.js - production configuration
module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: require('path').resolve(__dirname, 'dist'),
  },
  optimization: {
    // Mark unused exports for removal
    usedExports: true,
    // Analyze side effects
    sideEffects: true,
    // Use TerserPlugin to remove dead code
    minimize: true,
    minimizer: [
      new (require('terser-webpack-plugin'))({
        terserOptions: {
          compress: {
            drop_console: true,
            dead_code: true,
          },
          mangle: true,
        },
      }),
    ],
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        use: 'babel-loader',
        // Exclude node_modules by default, but ensure others are processed
        exclude: /node_modules/,
      },
    ],
  },
  // Use source maps in production to debug what's included
  devtool: 'source-map',
};

// src/utils.js - proper named exports for tree-shaking
// ✅ Good: named exports
export

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change