What a bundler actually does

It starts at your entry point and resolves every import to a file, applying the resolution rules in package.json exports and conditions, which is where most "cannot find module" errors actually come from. Each file is parsed to a syntax tree, its imports are followed, and the result is a graph of modules with the edges between them.

Then it removes what nothing uses. Tree-shaking is reachability analysis over that graph, and it is conservative by necessity: a module that runs code at import time might be doing something observable, so the bundler keeps it unless the package declares sideEffects: false. This is why importing one function from a badly packaged library can pull in the whole thing, and why the fix is a packaging change rather than an import change.

Code splitting cuts the graph at dynamic imports and route boundaries into chunks that load separately. Transforms lower syntax for your target browsers and rewrite JSX and TypeScript. Then it emits, with hashed filenames so that caches can be immortal, and a sourcemap so the stack traces still name your files. Every one of those steps is a place a build can go wrong, and naming the step is most of the debugging.