The Enterprise Frontend Blueprint - PART 2: The Build Pipeline & Developer Experience

The Pipeline Is the Product (For Your Team)

In Part 1 we talked about foundations — the monorepo, package management, directory boundaries, and runtime validation. The thread running through all of it was simple: be explicit, and don't trust defaults.

This part is about the second thing that quietly decides whether a large frontend codebase is pleasant or miserable to work in: the build pipeline and the developer feedback loop.

Here's the honest framing. Every second between "I saved a file" and "I know if it worked" is paid for. Not once - it's paid by every engineer, on every change, every day. It's a tax on focus that compounds into lost days per sprint.

I'll also be honest about something else, because it's relevant to everything below: The "correct" pipeline and the pipeline you can actually ship under a deadline are often different things. So I'll separate two voices throughout - what I've learned the hard way (opinion, earned), and what the wider community has measured and documented (evidence, cited). You should feel free to disagree with the first and verify the second.

Three questions drive this part:

• Should I still be on Webpack in 2026, and if not, what do I move to?
• Why is my CI so slow, and how do I actually fix it?
• How do I catch problems on the developer's machine before they ever reach CI?

Let's take them in order.

1. Moving Off Webpack: Choosing a Bundler in 2026 Without the Hype

Let me start by defending Webpack. Webpack wasn't a mistake. For a decade it did something genuinely hard — code splitting, tree shaking, an enormous loader ecosystem — and it did it before the alternatives existed. If you have a working Webpack build, it is not an emergency. Hold that thought; we'll come back to it.

Why it started hurting

The pain people describe online is real and it has a root cause, not a vibe. The common complaint reads like this (you've seen a hundred variants on r/reactjs and Stack Overflow):

"Our dev server takes two minutes to start and HMR takes 40–50 seconds. The team has stopped using watch mode."

The cause is architectural. Traditional Webpack does a large amount of JavaScript-based work to build a full dependency graph and bundle it before it can serve anything, and a cold start re-does most of that. As your module count climbs into the thousands, JS-based bundling simply runs out of headroom. This is why the entire ecosystem has been rewriting bundler internals in Rust and Go — esbuild, SWC, Turbopack, Rolldown, Rspack. It's not fashion; it's the only way to get another order of magnitude.

The thing you actually need to know first: Create React App is gone

If you maintain an older SPA, this is the most important sentence in this section. The React team formally deprecated Create React App on February 14, 2025 ("Sunsetting Create React App"), citing, among other things, a compatibility break with React 19. CRA now runs in maintenance mode with no active maintainers, and the React docs no longer recommend it.

I'm calling this out specifically because of how people hit it. As Redux maintainer Mark Erikson noted at the time, beginners still land on CRA through stale tutorials and old Google results, with nothing telling them it's a dead end. If you're starting something new, the official guidance is: use a framework (Next.js first), or a build tool like Vite, Parcel, or Rsbuild for a pure client-side app.

The 2026 landscape, stated plainly

Here's where things actually stand, with dates, because vague "X is faster now" claims are how articles rot:

Two of these deserve detail.

Vite 8 and the death of the dev/prod split. For years Vite made a pragmatic bet: esbuild for the dev server (fast), Rollup for production builds (optimized). It worked, but it created a whole category of bug that anyone who's shipped Vite has hit — "works in dev, breaks in the production build." Two bundlers, two behaviors, two tree-shaking implementations, two surfaces for things to differ. Vite 8 (per Vite's own announcement) replaces both with Rolldown, a single Rust bundler used for dev and prod. The headline is speed — Vite's benchmarks cite 10–30× faster builds than Rollup, and Linear publicly reported their production build dropping from 46s to 6s — but in my view the more important win is parity. One pipeline means the thing you test in dev is the thing you ship.

Turbopack is no longer optional in Next.js. Since Next.js 16 (October 2025), Turbopack is the default bundler for both next dev and next build, and it's marked stable; File System Caching went stable in 16.1. If you're on modern Next.js, you're already using it. Note that next.config custom webpack() plugins are not supported under Turbopack — that's the migration cost, and it's a real one for teams with bespoke loaders.

A decision framework instead of a winner

People want "which bundler is best" and that's the wrong question. The honest answer is that your framework usually decides for you:

• On Next.js? Use Turbopack. It's the default and the whole toolchain targets it now. Don't fight it.
• Standalone SPA (React/Vue/Svelte), no meta-framework? Vite. With Vite 8, the old dev/prod-parity caveat is gone, which removes my last reservation.
• Angular? The Angular CLI's application builder is already esbuild/Vite-based under the hood; you generally ride the CLI rather than picking a bundler directly. In an Nx workspace, the executor wraps this for you.
• Drowning in a 2,000-line webpack.config.js you can't afford to rewrite this quarter? Rspack/Rsbuild. It speaks Webpack's config language, so it's the lowest-friction way to get Rust-speed builds without a rewrite. This is the pragmatic, deadline-aware choice, and there's no shame in it.

The migration cost:

Speed posts skip the boring parts that actually break your build. The real gotchas, from release notes and migration threads:

• Node version floors moved. Vite 8 requires Node 20.19+ or 22.12+. Next.js 16 requires Node 20.9+. If your CI image or a teammate is on Node 18, that's step zero, and it will surprise someone.
• Config translation. Vite's manualChunks and some rollupOptions move to rolldownOptions; esbuild.minify* options relocate. Most plugins work unchanged because Rolldown implements the Rollup plugin API, but "most" is not "all."
• Install size. Vite 8 ships ~15 MB larger because it bundles the Rolldown binary and LightningCSS. Usually irrelevant; occasionally matters in constrained CI.
• Turbopack + custom Webpack = stop. No custom webpack() config, partial third-party loader support. Audit before you migrate, not after.

Where I land (the blended bit)

If you're greenfield in 2026, take the modern default for your framework and don't look back. If you have a working app, measure the pain before you migrate. My instinct is to rip out Webpack the moment something faster exists; experience (and a few deadlines I nearly missed chasing "correct") has taught me to wait until the slow feedback loop is actually costing the team real time. Migrate to fix a measured problem, not a release announcement.

2. Cutting CI From 30 Minutes to Under 8

The number depends entirely on your repo. So instead of selling you a trophy, let me give you the method I actually use, and you can find your own number.

Rule zero: measure before you optimize

Before touching anything, get the wall-clock split:

Total CI: 24m
├── checkout + install         8m   ← almost always the biggest, most fixable chunk
├── typecheck                  4m
├── lint                       3m
├── unit tests                 6m
└── build                      3m

Most teams guess "the tests are slow" and start there, when install and a lack of caching are eating a third of the run. Optimizing blind is how you end up with a fragile "fast" pipeline that silently regresses. Measure, then attack the biggest bar.

Lever 1 — Cache the right thing

The single most common CI mistake I see in issues and PRs: people cache node_modules. Don't. Cache the package manager's content-addressable store and let install relink from it. For pnpm in GitHub Actions:

- uses: pnpm/action-setup@v4
  with:
    version: 10.17.1            # pin it; don't float your package manager

- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'pnpm'              # caches the pnpm store, keyed on the lockfile

- run: pnpm install --frozen-lockfile

Two details that matter: --frozen-lockfile makes CI fail loudly if the lockfile and package.json disagree (you want that), and pinning the package manager version avoids the "works locally, breaks in CI" resolution differences. A warm pnpm store routinely turns a multi-minute install into seconds.

Lever 2 — Do less work, not faster work

The biggest wins in a monorepo come from not running things that don't need to run. This is where Nx earns its keep. nx affected walks the project graph and runs tasks only for projects touched by your diff:

# Only lint/test/build what this PR actually changed
nx affected -t lint test build --base=origin/main --head=HEAD

Turborepo's equivalent is turbo run build --filter=...[origin/main]. Pair either with remote caching (Nx Cloud, Turborepo Remote Cache) so that if a task's inputs haven't changed, CI replays the cached result instead of recomputing it — including across machines and across your teammates' runs. And tie this back to Part 1: the CODEOWNERS path filtering we set up there is the same idea applied to triggering — only run a pipeline when its paths change.

A caution from experience: affected is only as honest as your project graph. If a library has an implicit dependency the graph doesn't know about, affected can skip something it shouldn't. Keep your nx.json inputs and module boundaries accurate, or the optimization will occasionally lie to you.

Lever 3 — Parallelize and shard

Typecheck, lint, and build don't need to run sequentially. Split them into parallel jobs. Split a big test suite into shards across matrix runners. As a concrete, real example: the repo this article is being drafted in runs CI as four parallel jobs — lint+typecheck and build, separately for each of its two apps — rather than one long serial pipeline. That's the pattern. Fan out, then gate the merge on all of them.

Lever 4 — The build tool and the runner (and a 2026 trap)

The Rust bundlers from Section 1 help here too: a faster build is a faster CI build step. Bigger runners cut time at a money cost — sometimes worth it, since most CI providers bill per-minute, not per-core, so a 2× runner that halves the time can be cost-neutral.

But here's the trap that's biting teams right now, and it's worth knowing before it pages you: Turbopack production builds use more memory than Webpack did, and Next.js 16's default build can blow past Vercel's standard 8 GB build container with JavaScript heap out of memory. The community-documented fix is not to naively set --max-old-space-size=8192 (the build agent itself needs headroom and you'll trip the OOM killer again). It's to raise the heap to roughly 7168 MB, or move to a larger build machine, and — notably — to drop wildcard barrel re-exports and use optimizePackageImports, because the module graph size is what's inflating memory. That last point is the exact barrel-file discipline we argued for in Part 1, now showing up as a build-time cost.

// vercel.json — give the build machine real headroom (Pro plan)
{ "build": { "memory": 16384 } }

The correctness trap underneath all of this

Caching and affected make CI fast by trusting that unchanged inputs produce unchanged outputs. When a build is nondeterministic — a timestamp baked into output, an unpinned dependency, a hidden environment difference — a cache can serve you a stale or wrong result, which is far worse than a slow-but-honest pipeline. Get build determinism right (pinned versions, clean inputs, no latest tags) before you lean hard on remote caching.

Where I land

"Under ten minutes" is achievable for a well-cached, well-graphed monorepo, and genuinely impossible for some large repos no matter what you do — and that's fine. Ship the method: measure, cache the store, run only what's affected, parallelize, keep builds deterministic. Then stop when the curve flattens. Chasing the last 30 seconds is the perfectionist trap;

3. Git Hooks That Catch Problems Before Code Leaves the Machine

The cheapest place to catch a problem is on the developer's laptop, before it ever costs a CI minute or a reviewer's attention. That's what local git hooks are for. But this is also the area where I see the most quietly-broken setups, so let's get it right and current.

Start with the right mental model

Hooks are fast local feedback. They are not a security boundary. A developer can bypass any hook with --no-verify, and they will, especially under deadline pressure. So the rule is: CI is the real gate; hooks are the courtesy that keeps obvious mistakes out of CI in the first place. Design around that and you'll make better choices. Pretend hooks are enforcement and you'll build something both annoying and unreliable.

Husky in 2026: the migration almost everyone is mid-way through

If you use Husky and haven't looked at it lately, you've probably seen this in your install logs:

husky - DEPRECATED ... "Please remove the following lines from your hook scripts ... They WILL FAIL in v10.0.0"

This is real and it's tracked in Husky issue #1480. Two things changed:

• The two-line preamble is deprecated. Older hooks started with #!/usr/bin/env sh and . "$(dirname -- "$0")/_/husky.sh". Those lines must be removed from every file in .husky/; they will break in v10.
• husky install is deprecated. The modern setup is just husky invoked via the prepare script.

A correct, v10-ready setup looks like this:

// package.json
{
  "scripts": {
    "prepare": "husky"
  }
}

# .husky/pre-commit — no shebang preamble, no sourcing husky.sh
pnpm lint-staged

That's it. If you're staring at a .husky/pre-commit with the old preamble still in it, that's your weekend-saving five-minute fix.

Keep the hook fast, or it gets bypassed

This is the part teams get emotionally instead of practically. If your pre-commit takes 40 seconds, developers will --no-verify it, and then you have a hook that runs only for the disciplined people who least need it. The fix isn't a lecture about discipline — it's lint-staged, which runs your tools only against the files actually staged:

// lint-staged.config.mjs
export default {
  "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
  "*.{json,md,css}": ["prettier --write"],
};

My personal budget: if pre-commit can't stay under ~60 seconds, it's doing too much. Move the heavier checks outward.

The bug that wastes time: hooks don't fire in the editor

Here's one straight from real-world support threads (and one this very codebase keeps a dedicated doc for): hooks run fine from the terminal but silently do nothing when you commit through the Cursor / VS Code / JetBrains UI. People assume their setup is broken; it usually isn't. The editor's Git integration often runs with a different PATH or shell and can't find Node/pnpm, so the hook fails to launch — sometimes silently. The fixes are mundane but worth documenting for your team: ensure the editor uses the right shell/Git, make sure the package manager is on the GUI's PATH, and disable "allow commit without hooks" settings. The lesson is broader than the bug: if a hook can fail silently, half your team is already not running it.

Layer your checks — put each at the cheapest place that can catch it

The most common design mistake is cramming everything into pre-commit. Spread it out:

Optionally add a commit-msg hook (e.g. commitlint for Conventional Commits) if your release tooling derives changelogs/versions from commit messages — but only if it earns its place. Don't add ceremony for ceremony's sake.

Where I land

Don't moralize about --no-verify. Make hooks fast enough that bypassing them feels unnecessary, document the editor gotcha so nobody loses an afternoon, and let CI be the backstop you actually trust. Hooks are there to be kind to your future self and your reviewers — not to police your teammates.

Tying It Together

If Part 1 was about structure — where code lives and what it's allowed to depend on — Part 2 is about speed of truth: how quickly, and how honestly, your tooling tells a developer whether their change is good.

The through-line is one idea: put every check at the cheapest layer that can catch it, and measure instead of guessing. Format in the editor. Catch the obvious in a fast hook. Run only what's affected, with a warm cache, in parallel, in CI. Choose the bundler your framework already blesses, and only migrate to fix a problem you've actually measured.

And one last honest note: the goal is not the perfect pipeline. It's the pipeline that gives your team fast, trustworthy feedback and then gets out of the way so you can ship. Good pipeline you have today beats a perfect one you're still tuning next quarter. Deadlines are real. Build the loop that respects them.

Next up — Part 3: Testing & Release Confidence. We'll get into the test pyramid as it actually survives contact with a large monorepo, why most teams over-invest in slow end-to-end tests and under-invest in fast contract tests, how to make flaky tests a build-breaking bug instead of a fact of life, and the release patterns — feature flags, canaries, and instant rollback — that let you ship on a Friday and sleep that night.