Frontend Architecture
Build pipelines: multiple-choice review
Crux Multiple-choice synthesis across the build-pipeline unit — stage seams, tree-shaking defeats, dev/prod parity, content hashing, and tool-speed tradeoffs.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a call you make while a bundle regresses, a dev-only bug ships, or a build step times out CI — not a definition to recite, but a tradeoff to weigh.
Goal
Confirm you can connect the five pipeline stages, why tree-shaking fails, why dev and prod diverge, and how content hashing and tool choice trade off — the synthesis the overview built toward.
Quiz
Completed
A teammate swaps import debounce from 'lodash/debounce' for import _ from 'lodash' and the main bundle grows ~200 KB. Why did tree-shaking not drop the unused functions?
Heads-up Tree-shaking is on by default in production bundles. The defeat here is module format — CommonJS exports are computed at runtime and cannot be statically analysed.
Heads-up Stage order is not the cause. Even with correct ordering the bundler keeps the whole CJS module because its exports are not statically analysable.
Heads-up Import style is not the root cause — module format is. ES modules shake regardless of default vs named; CommonJS does not shake either way.
Quiz
Completed
A clean ESM utility library still ships dead code after bundling, even though every import looks unused. The most likely cause?
Heads-up Bundlers tree-shake arbitrarily large ESM graphs. Size is irrelevant; the missing sideEffects contract is what forces the bundler to keep modules.
Heads-up Tree-shaking removes unused exports at binding granularity within a module, not just whole files. The sideEffects flag governs whether a file may be dropped at all.
Heads-up Source maps are debugging metadata emitted last; they never keep code in the bundle. The sideEffects declaration is the lever.
Quiz
Completed
A feature works in the Vite dev server but breaks after vite build. What is the most likely structural cause, not a one-off?
Heads-up Stale cache makes old behaviour persist, the opposite symptom. A true dev/prod split is two different toolchains producing different output from the same source.
Heads-up Minification can occasionally surface a latent bug, but the structural reason dev and prod diverge is that they run different bundlers on differently-shaped module graphs.
Heads-up Both modes inline env vars; the divergence here is bundling architecture, not env handling. The fix is to test the real prod build, not to chase env injection.
Quiz
Completed
Why does swapping Babel for esbuild or SWC cut the transform stage by 90%-plus, while the bundle stage rarely sees the same speedup?
Heads-up esbuild produces correct output; the speedup comes from a compiled language, real threads, and a single shared AST — not from skipping necessary work.
Heads-up Config format is irrelevant to runtime cost. Babel is slow because it is single-threaded JavaScript re-parsing ASTs; the bundle stage stays serial regardless of transformer.
Heads-up Bundling is whole-graph and largely serial — that is exactly why transform-stage speedups do not carry over to it.
Quiz
Completed
Returning users re-download the large vendor chunk on every app deploy even though React and your deps never changed. The fix?
Heads-up Stable filenames break cache busting entirely — users would be served stale app code. The fix is chunk boundaries, not removing the hash.
Heads-up Revalidating more often increases traffic, the opposite goal. With content hashing you want a long max-age plus immutable; the real issue is vendor sharing a chunk with app code.
Heads-up Inlining vendor into app chunks guarantees its hash changes on every app deploy, busting the cache every time — exactly the problem here.
Quiz
Completed
Source is clean ESM, yet the prod bundle still ships an entire dependency it should have shaken. The transform stage is the suspect — why?
Heads-up Tree-shaking happens during the bundle stage on the module graph, not during per-file transform. The transform-stage defeat is ESM-to-CJS down-leveling, which removes the static structure shaking needs.
Heads-up Transform and minify are separate stages; transform does not minify. The real defeat is down-leveling ESM to CommonJS before bundling.
Heads-up esbuild tree-shakes ESM well; the issue is that a Babel transform can convert ESM to CJS upstream, after which no bundler can shake it.
Recap
The through-line: a build is resolve → transform → bundle → minify → emit, and the seams between stages are where bugs live. Tree-shaking needs static ESM, so it is defeated by CommonJS, by undeclared side effects, and by transforms that down-level ESM to CJS before the bundler looks. Transform is parallel (so compiled tools win there) while bundle stays serial. Dev and prod run different tools, so validate the real prod build. And content hashing only pays off if you split stable vendor code from churny app code.