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.