Build Tools & Bundlers Interview Questions and Answers

Webpack bundles everything up front: it builds the whole dependency graph, then serves from memory, so cold starts grow with project size. It is extremely configurable through loaders and plugins, supports virtually every asset type, and has a mature ecosystem plus Module Federation.

Vite takes another approach. In development it serves your source over native ESM and transforms files on demand, so the server starts almost instantly regardless of app size. Dependencies are pre-bundled once with esbuild. For production it uses Rollup, and increasingly Rolldown, to produce an optimised tree-shaken bundle, so dev and prod differ internally.

Vite has sensible defaults, built-in CSS and asset handling, fast HMR and a simpler config, but a smaller plugin surface than webpack and occasional dev-versus-build differences.

Choose Vite for most new apps for speed and simplicity. Choose webpack when you need a specific loader, Module Federation or deep legacy compatibility.

CommonJS is Node's original system: require() is a function executed at runtime, module.exports is a mutable object, resolution can be dynamic and conditional, and modules are evaluated synchronously on first require, then cached.

ES modules use static import and export syntax declared at the top level. They are parsed before execution, hoisted, provide live bindings so an imported value reflects later changes, and support top-level await. Because imports are static, bundlers can tree-shake and analyse dependencies; because CommonJS is dynamic, they generally cannot.

Interop caveats: importing CommonJS from ESM usually gives a default export of module.exports, and named imports work only through tooling analysis. In Node, "type": "module" makes .js files ESM, while .cjs and .mjs force a format.

Dual-publishing a library requires a build for each format with correct exports conditions, and mixing them can cause the dual package hazard where two copies of state exist.

Code splitting divides the bundle so the browser downloads only what a route or interaction needs. Bundlers detect dynamic import() and create a separate chunk for that module and its exclusive dependencies. Shared dependencies may be hoisted into a common chunk to avoid duplication.

button.addEventListener('click', async () => {
  const { renderChart } = await import('./chart.js');
  renderChart();
});

Route-based splitting is the highest-value pattern, because initial load only pays for the current page. Vendor splitting separates rarely changing libraries into their own chunk so browser caching survives app updates, and framework configs often expose manualChunks or similar.

The trade-offs are more requests, duplicated code risk and a flash while a chunk loads. Mitigate with preload or prefetch, such as link rel="modulepreload" and router prefetching, plus loading states. Set hashed chunk file names for long-term caching, measure with a bundle analyser, and avoid splitting so finely that request overhead dominates.

Hot Module Replacement updates modules in a running app without a full page reload, preserving application state and often scroll position. When a file changes, the dev server sends the updated module over a WebSocket. The runtime accepts the new version and re-executes it, or asks the framework to re-render the affected component.

Frameworks implement an HMR boundary: React Fast Refresh re-mounts the component while keeping state where possible, and Vue and Svelte do something similar at component level. If no boundary accepts the update, the tool falls back to a full reload.

HMR requires a dev server such as Vite or webpack-dev-server and works best with components that have clear module boundaries. Editing a module-level side effect or an exported constant often forces a reload. It is a development-only feature stripped from production, and it pairs with fast incremental builds to give quick feedback without losing the state you were testing.