Module Graph
The directed graph of imports that decides what code ends up where.
The module graph is the structure a Bundler builds by starting at entry points and following every import: nodes are modules, edges are imports. Almost everything about a built application — what ships, what can be removed, what runs where — is a property of this graph rather than of any individual file.
The practical implication is that membership is transitive and easy to acquire by accident. Importing one small helper from a module that also imports a large library puts that library in the graph. Importing a type-only value through a barrel that re-exports components puts those components in the graph. A file's own contents tell you nothing about whether it is expensive; its position in the graph does.
This also explains a class of confusing failures that have nothing to do with size. Two build environments can disagree about a module's identity or ordering, which changes downstream hashes. A test runner and a browser runner can each instrument the same file, so a file loaded in both is measured twice — producing coverage shortfalls in files nobody edited. And a value imported through the wrong path drags a component into an environment it was never meant to run in.
Reading the graph — from the bundler's own manifests rather than by inference — is what converts guesses into facts. See Ground Truth.
See also6
Hand-picked in the note itself — the neighbours worth reading next.
Code Splitting
Dividing an application bundle so a page downloads only the code it needs.
Web Platform12 connections
Tree Shaking
Statically removing exports that nothing imports, shrinking the shipped bundle.
Web Platform9 connections
Client-Server Boundary
The line in an application where execution moves from the server to the browser.
Web Platform10 connections
Code Coverage
The proportion of code executed by a test suite — a map of what is untested, not a measure of quality.
Testing & Verification12 connections
React Server Components
Components that execute only on the server and never ship their code to the browser.
Web Platform16 connections
Lazy Loading
Deferring the fetch of a resource until it is needed, or until the browser is idle.
Web Platform12 connections
Related2
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from14
Notes elsewhere in the wiki that reach for this one.
- BundlerWeb Platform
The tool that resolves an application's modules into the files a browser downloads.
- Client-Server BoundaryWeb Platform
The line in an application where execution moves from the server to the browser.
- Code CoverageTesting & Verification
The proportion of code executed by a test suite — a map of what is untested, not a measure of quality.
- Code SplittingWeb Platform
Dividing an application bundle so a page downloads only the code it needs.
- Islands ArchitectureWeb Platform
Rendering a page as static HTML with small independently interactive regions.
- Lazy LoadingWeb Platform
Deferring the fetch of a resource until it is needed, or until the browser is idle.
- LockfileVersion Control & Delivery
A generated file recording the exact dependency versions an install resolved to.
- MonorepoSystems & Tooling
Several packages developed in one repository with shared tooling and atomic cross-package changes.
- Package ManagerSystems & Tooling
The tool that resolves, fetches, and installs dependencies, and pins them for reproducibility.
- Performance BudgetWeb Platform
A committed numeric ceiling on a page's cost, enforced automatically.
- React Server ComponentsWeb Platform
Components that execute only on the server and never ship their code to the browser.
- Tree ShakingWeb Platform
Statically removing exports that nothing imports, shrinking the shipped bundle.
- Unit TestTesting & Verification
A fast, isolated test of one unit of behaviour with its collaborators replaced.
- Web Font LoadingWeb Platform
How custom typefaces are fetched and shown, and why the cost is easy to misattribute.