An Angular app reaches the browser through a chain of compilers and bundlers most developers happily ignore — until a bundle warning fires or ng serve does something weird. This lesson opens the hood. By the end you will know what ng serve and ng build actually do, why esbuild and Vite both show up, what AOT compilation produces, where source maps come from, and how to tune the budget warnings that catch bloat before deploy.

This is lesson 1.5 of the Angular Tutorial — the closing lesson of Module 1. You can build apps without understanding any of this, but the first time your bundle balloons or a build fails, knowing the layer cake is worth half an hour of head-scratching.

The layer cake in one paragraph #

Angular's build pipeline since v17 is a stack of four tools doing four jobs. The Angular compiler (called @angular/compiler-cli or ngc) reads your .ts files and your template HTML and emits enriched JavaScript with all the framework's compile-time work baked in. esbuild then bundles that JavaScript into a small number of .js chunks. Vite drives the development server — file watching, HMR, on-demand transforms. Terser minifies the production output. Most projects never touch any of these directly; they all sit behind the ng build and ng serve commands.

What ng build does, step by step #

Run ng build (defaults to the production configuration in v17+) and the following happens, in order:

1. Discovery. The CLI reads angular.json, finds the project's build target, resolves entry files (main.ts, polyfills.ts).
2. Compilation. The Angular compiler runs in AOT mode. It reads .ts files, parses every template in every component, type-checks the templates against the component class, and emits enriched JavaScript modules.
3. Bundling. esbuild takes the compiled JS, follows the import graph from main.ts, and produces optimized chunks — one main bundle plus one per lazy route plus one per @defer block.
4. Asset processing. Files in public/ are copied to the output. CSS is inlined or extracted depending on configuration.
5. Minification. Terser runs over the production output (skipped for dev builds).
6. Budget check. The CLI compares final chunk sizes against budgets in angular.json and emits warnings or errors.
7. Output. Everything lands in dist/<project-name>/browser/ (and /server/ for SSR builds).

Development builds skip steps 5 and 6 and use a single non-optimized chunk per route boundary to make HMR fast. The output directory is the same; the contents are slower and bigger.

AOT vs JIT — and why JIT is dead in 2026 #

Angular has two compilation modes:

v17 made AOT the default. v18 removed JIT from production builds entirely. v20 deprecated it for dev builds too. In 2026 every Angular app you write or read uses AOT. You may see the term in older blog posts and Stack Overflow answers — treat "AOT vs JIT" as ancient history.

The practical benefit you feel daily: template errors fail at build time, not runtime. Misspelled bindings, wrong types, missing imports — all caught by ng serve before you reload the browser.

esbuild — the bundler since v17 #

Angular shipped its own webpack-based bundler for a decade. In v17 the team rewrote the build pipeline on top of esbuild, written in Go and roughly 100x faster than webpack at typical project sizes. The migration was transparent for application code — you do not import esbuild, configure it, or even see it in stack traces unless something goes wrong.

What changed for you:

• Cold builds in seconds, not minutes. A project that took 45 seconds on webpack typically builds in 4 with esbuild.
• Incremental dev rebuilds in sub-100ms. HMR is no longer noticeably slower than the file save.
• Smaller production output. esbuild's tree-shaking and minification are more aggressive than the older webpack setup.

The trade-off was loss of the deep webpack plugin ecosystem. Most apps never used those plugins; the few that did stayed on the legacy application builder for a release or two. By 2026 the legacy builder is gone from new projects.

Vite — the dev pipeline since v18 #

esbuild handles bundling. Vite handles the development experience: file watching, HMR over a WebSocket, on-demand module transforms, the dev server itself. Angular wrapped Vite in v18 and made it the default dev server in v19.

Why Vite alongside esbuild? Because esbuild is great at bundling-the-world but slower at incremental "transform this one file I just saved." Vite's on-demand model serves each file when the browser requests it, transforms it, and caches the result. The combination — Vite for dev, esbuild for production bundling — is what gives Angular 2026 its sub-second feedback loop.

You see Vite in the dev-server output (VITE v6.0.0 ready in 432 ms) and in error overlays. Otherwise it is invisible.

Production output: what's in dist/ #

A typical production build produces:

dist/my-app/browser/
├── index.html                    ← Updated to reference hashed chunk names
├── main-XXXXXX.js                ← Your app's main bundle
├── chunk-XXXXXX.js               ← Per-route lazy chunks
├── chunk-XXXXXX.js               ← @defer block chunks
├── polyfills-XXXXXX.js           ← Browser polyfills (zone.js if not zoneless)
├── styles-XXXXXX.css             ← Global styles, concatenated
├── favicon.ico                   ← From public/
├── 3rdpartylicenses.txt          ← License roll-up of npm deps
└── ...static assets

File names include content hashes for cache-busting. Deploy this folder to any static host — Netlify, Vercel, Cloudflare Pages, S3 + CloudFront, an Nginx box — and you have a working Angular app. SSR builds also produce a server/ sibling directory with the Node entry point.

Build configurations #

The angular.json architect.build.configurations block defines named configurations — typically development and production. The --configuration flag picks one:

ng build --configuration=production    # default
ng build --configuration=development
ng build --configuration=staging       # if you defined one

A typical configuration block:

"production": {
  "budgets": [
    { "type": "initial", "maximumWarning": "500kB", "maximumError": "1MB" },
    { "type": "anyComponentStyle", "maximumWarning": "4kB" }
  ],
  "outputHashing": "all",
  "fileReplacements": [
    { "replace": "src/environments/environment.ts",
      "with":    "src/environments/environment.prod.ts" }
  ]
}

The three knobs worth knowing:

• budgets — warn or error when chunk sizes exceed thresholds (see next section)
• outputHashing — all adds content hashes to every output file (the cache-busting default)
• fileReplacements — swap one file for another at build time, used for env config

Source maps — production and otherwise #

Source maps map minified JavaScript back to the original .ts files for debugging. By default:

For production debugging — Sentry, browser DevTools on a deployed build — you can serve the .js.map files alongside the .js. To opt in:

"production": {
  "sourceMap": { "scripts": true, "styles": true, "hidden": false }
}

Most teams keep production source maps hidden (security + bundle size) and upload them to their error-tracking service instead. Sentry's Angular SDK does this automatically with the right CLI config.

Budgets — catching bloat at build time #

Budgets are size thresholds that fail the build (or warn) when a chunk grows past a limit. The defaults from a fresh ng new:

Do not raise the warning threshold the moment it fires. The warning is the canary. Investigate first:

npx source-map-explorer dist/my-app/browser/main-*.js

That opens an interactive treemap showing exactly which dependencies own which bytes. Nine times out of ten the bloat is a single heavy package (moment.js, lodash imported whole, a UI lib you don't actually use) — fix that, not the budget. Lesson 8.5 (Bundle Analysis & Tree-Shaking) walks the full diagnose-and-fix loop.

Common gotchas #

What's next #

This closes Module 1. You have walked the entire surface a developer touches before writing application code: what Angular is, how the CLI scaffolds, the bootstrap flow and ApplicationConfig, dependency injection from both sides, the TypeScript subset that matters, and the build pipeline. From here on the tutorial gets practical — Module 2 is the longest, walking components, templates, signals queries, pipes, directives, host metadata, and the rest of the day-to-day surface.

Module 3 dives into signals deeply — the reactive primitive that replaced most everyday RxJS use. Module 4 picks up forms (including signal forms, the v22 way). Modules 5 through 9 cover routing, HTTP, RxJS in modern Angular, CSR performance, and SSR performance. Module 10 is the debugging cookbook. Modules 11 through 13 round out testing, AI × Angular, and animations.

Try it yourself #

The sharpest end-to-end demo of the pipeline is to build the same app two ways and compare sizes:

ng build --configuration=development
ls -lh dist/my-app/browser/main-*.js     # ~2-4 MB typically

ng build --configuration=production
ls -lh dist/my-app/browser/main-*.js     # ~100-300 KB typically

The dev build is faster to produce and bigger to ship; the prod build is the reverse. Walk the prod output through source-map-explorer (npx source-map-explorer dist/my-app/browser/main-*.js) to see exactly where the bytes went. You will be surprised — and that surprise is the first step toward an app that loads in under a second.

Module 1 is complete. The tutorial's launch milestone has arrived. Module 2 — Components & Templates — starts in the next lesson.