Build Tools & Bundlers Interview Questions and Answers

Browsers can load ES modules, but a large app would issue hundreds of requests, and TypeScript, JSX, CSS and assets all need processing. A bundler takes an entry point, follows imports to build a dependency graph, transforms each module, and emits a small number of optimised files.

It handles transpilation through loaders or plugins, resolves bare imports from node_modules, inlines or copies assets, splits the output into chunks, minifies it, and generates cache-busting hashes. It also powers development with a local server and hot module replacement.

The goal is fewer requests, smaller payloads, compatibility with older browsers and a reproducible pipeline from source to deployable assets. Modern bundlers such as Vite, esbuild and SWC reduce the cost, but the core reasons stay the same: dependency resolution, transformation and output optimisation. Without a bundler you would manage script order and duplicate dependencies by hand.

Babel is a JavaScript compiler that transforms modern syntax into code older environments can run. It parses source into an AST, applies plugins that each handle a transformation such as arrow functions, optional chaining, class fields or JSX, and generates new code.

Presets bundle common plugin sets. @babel/preset-env uses your browserslist or targets to include only the transforms needed, while @babel/preset-react and @babel/preset-typescript handle JSX and TypeScript syntax. It can add polyfills through core-js with useBuiltIns: 'usage', though Babel does not polyfill language features automatically without that.

{ "presets": [["@babel/preset-env", { "targets": ">0.5%, not dead" }]] }

Babel operates file by file and is relatively slow, so modern toolchains often replace it for transpilation. It does not bundle; that is the bundler's job. Babel remains valuable for custom transforms, macros and precise browser targeting.

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.

Tree shaking removes unused exports from the final bundle. It relies on ES modules being statically analysable: imports and exports are known at parse time, so the bundler can build a graph, mark reachable bindings, and drop the rest. It works best when modules are side-effect free, which is why package.json has "sideEffects": false or an array listing files that do have side effects. Without that hint the bundler keeps imports whose removal could change behaviour.

What breaks it: CommonJS require, because imports can be dynamic and conditional. Importing a namespace and accessing properties dynamically, such as import * as x and x[name]. Re-export barrels that pull in everything. Top-level code with side effects. Usage that cannot be statically traced.

Minifiers then remove dead code within a module, so production builds must be minified; unminified output often still contains unused code. Use named imports, avoid side effects at module scope, and inspect the bundle with rollup-plugin-visualizer or webpack-bundle-analyzer.

Library builds differ from app builds: you usually bundle to ESM and CommonJS, externalise peer dependencies such as React or Vue so consumers do not get duplicates, generate type declarations, and avoid bundling polyfills. Rollup is the classic choice because its output is clean and tree-shakeable, and tools like tsup, unbuild and Vite's library mode wrap it with sensible defaults. Configure exports with conditions for import, require and types, set sideEffects: false when true, and keep entry points minimal so consumers only pull what they use.

{
  "main": "./dist/index.cjs",
  "module": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "sideEffects": false
}

For analysis, webpack-bundle-analyzer and rollup-plugin-visualizer show a treemap of module sizes. Common findings are a library imported wholesale, duplicated versions, all moment locales, or lodash pulling everything. Fix with per-function imports, aliasing to lighter alternatives, manualChunks for vendors, and checking duplicates with npm ls. Always measure gzipped or brotli sizes, not raw bytes.