intermediate

Webpack

Configure loaders, plugins, module graph optimization, code splitting, asset handling, and long-lived project migrations.

Webpack builds a module dependency graph and transforms files through loaders (per-file) and plugins (graph-wide). It remains common in large apps because of deep configurability and enterprise integrations.

| Concept | Role | |---------|------| | Loader | Transform a module type (TS, CSS, assets) | | Plugin | Optimize graph, emit HTML, split chunks | | `splitChunks` | Vendor and async route separation | | `sideEffects` | Tree-shaking hints in `package.json` |

					module.exports = {
  module: {
    rules: [{ test: /\.tsx?$/, use: 'ts-loader' }],
  },
  optimization: { splitChunks: { chunks: 'all' } },
};
				

Dev server (`webpack-dev-server`) and persistent filesystem cache speed iterative work. Source maps and bundle analyzers diagnose production size.

On interviews: loaders vs plugins, code splitting strategy, tree-shaking limits with CJS, long-term cache filenames, and migration off Webpack.

Common pitfalls: config sprawl hiding slow builds; importing entire libraries; disabling sideEffects awareness.

The trade-off is flexibility and ecosystem depth versus configuration cost and build time.

Checklist:

  • Know loader/plugin responsibilities.
  • Measure bundles with analyzer tools.
  • Align `sideEffects` with real module behavior.
  • Use caching with invalidation discipline.