diagram.mmd — flowchart
Module Bundling Workflow flowchart diagram

Module bundling is the process by which a build tool takes a graph of JavaScript module files (plus CSS, images, fonts, and other assets), resolves all their dependencies, transforms them, and outputs optimized files suitable for delivery to a browser.

The bundler's work begins with one or more entry points — the top-level files that the application starts with (src/main.js, src/index.tsx). The bundler reads each entry point, parses it into an AST (Abstract Syntax Tree), and finds all import and require statements. It recursively follows each import to build a dependency graph — a directed acyclic graph where each node is a module file and each edge is an import relationship.

As the graph is built, each module is processed through a pipeline of loaders (webpack) or plugins (Vite/Rollup). TypeScript files are transpiled to JavaScript. JSX is transformed into React.createElement or equivalent calls. CSS modules are converted to scoped class names. Images below a size threshold are inlined as base64 data URIs. Babel transforms modern JavaScript syntax to a target compatibility level.

With the full graph loaded and transformed, the bundler performs tree shaking — dead code elimination based on static analysis of ES module import/export statements. Modules or exports that are imported but never used are excluded from the output. This is why switching from CommonJS (require) to ES modules is a prerequisite for effective tree shaking: CommonJS exports are dynamic and cannot be statically analyzed.

The remaining modules are concatenated into output chunks. A single-chunk build produces one large JS file; code splitting (see Code Splitting Architecture) produces multiple smaller chunks. Finally, the bundler minifies output (removing whitespace, shortening variable names) and optionally generates source maps for debugging. Hashed filenames are added for long-term caching. See Lazy Loading Components for how dynamic imports create async chunk boundaries in this graph.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

Module bundling is the build-time process of taking a graph of JavaScript modules (plus CSS, images, and other assets), resolving all their `import`/`require` dependencies, transforming them (TypeScript, JSX, CSS modules), and outputting optimised, browser-ready files. Webpack, Vite, and Rollup are the most widely used bundlers.
Tree shaking uses static analysis of ES module `import` and `export` statements to identify code that is imported but never actually used, then excludes it from the output. It relies on ES modules being statically analysable — CommonJS `require` calls are dynamic and cannot be tree-shaken reliably, which is why migrating to ES module syntax is a prerequisite for effective dead code elimination.
Vite is the default choice for new projects: it uses native ES modules in development (no bundling step, so dev server starts instantly) and Rollup for production builds. Webpack is better for complex, large legacy codebases with highly customised build pipelines, advanced `splitChunks` configurations, or ecosystem plugins not yet available in Vite. For greenfield projects, Vite's speed advantage in development is significant.
The most impactful mistakes are: importing entire libraries when only one function is needed (preventing tree shaking), not configuring `splitChunks` or `manualChunks` so all vendor code lands in one giant chunk, committing unminified production builds, and omitting content hashes from output filenames so browsers cannot safely use long cache TTLs.
mermaid
flowchart TD A[Entry Point — src/main.js] --> B[Parse into AST] B --> C[Find All Imports and Requires] C --> D[Resolve Module Paths] D --> E{All dependencies loaded?} E -- No --> F[Load Next Module File] F --> B E -- Yes --> G[Full Dependency Graph Built] G --> H[Run Loaders and Plugins] H --> I[TypeScript and JSX Transform] I --> J[CSS and Asset Processing] J --> K[Tree Shaking — Remove Unused Exports] K --> L{Code splitting configured?} L -- Yes --> M[Split into Multiple Chunks] L -- No --> N[Single Output Bundle] M --> O[Concatenate and Minify Each Chunk] N --> O O --> P[Generate Hashed Filenames] P --> Q[Write Output Files and Source Maps] style Q fill:#22c55e,color:#fff
Copied to clipboard