Frontend Architecture
Build pipelines: audit and harden a real build
Reading about tree-shaking and dev/prod parity is not the same as cutting a 200 KB regression out of a real bundle and proving it stayed out. Take a real app, measure its build, find the leaks, fix them at the right stage, and back every claim with a number.
Turn the unit’s mental model into a reproducible engineering loop: analyse the bundle, find the tree-shaking and chunking leaks, fix them at the right pipeline stage, close a dev/prod parity gap, and verify with before/after measurements — not estimates.
Take a real frontend app (your own, or a starter you scaffold with a deliberately CommonJS-heavy dependency) and harden its build: shrink the production bundle by eliminating a tree-shaking regression, stabilise caching with a vendor split, close one dev/prod parity gap, and prove each fix with before/after numbers.
- A before/after table: total bundle bytes, vendor vs app chunk sizes, cold vs warm build time, and the tree-shaking regression's contribution — all measured from the analyzer and build output, not estimated.
- The analyzer treemaps before and after clearly show the CommonJS regression gone and vendor isolated into its own chunk.
- Proof of cache stability: two consecutive builds with only an app-code change, showing the vendor chunk filename (hash) unchanged across both.
- A CI run log showing the production-build smoke test catching the parity bug, then passing after the fix.
- A one-paragraph write-up naming which pipeline stage each fix targeted (resolve/transform/bundle/minify/emit) and why that was the right stage.
- Add a bundle-size budget gate to CI (size-limit or the bundler's performance budget) that fails the build if any chunk grows beyond a threshold, and demonstrate it catching a reintroduced regression.
- Migrate the transform stage from Babel to esbuild or SWC and record the transform-time delta on a cold build, isolating it from the bundle stage.
- Add a second build target (modern + legacy via differential output) and compare the modern bundle's size against the down-leveled one, showing the cost of supporting old browsers.
- Write a one-page build runbook: how to read a treemap, the tree-shaking defeat checklist (CJS / sideEffects / down-leveling), the vendor-chunk caching rule, and the dev/prod verification gate.
This is the loop you will run on every real build: analyse first with a treemap, find the leak (a CommonJS import, an over-broad sideEffects flag, vendor sharing a chunk with app code), fix it at the right stage (resolve, transform, bundle, or emit), close the dev/prod gap with a CI gate on the real production build, and verify with before/after numbers under the same conditions. Doing it once on a real app makes the production version muscle memory.