Building and Deploying an Angular App

Analogy categoryAnalogies

Running ng build compiles an Angular application into static HTML, CSS, and JavaScript assets ready for deployment. By default, the CLI uses the production configuration defined in angular.json, which enables Ahead-of-Time (AOT) compilation, minification, tree-shaking, and differential loading. AOT compiles templates into efficient JavaScript instructions at build time rather than in the browser at runtime, producing smaller bundles and faster startup than the Just-in-Time (JIT) compilation used during local development with ng serve.

🏏

Cricket analogy: AOT compiling templates ahead of time is like a batter shadow-practicing every ball of a bowler's over the night before, so on match day at the WACA they react instantly instead of reading the delivery live like JIT does during net practice.

Build Configurations and Environments

angular.json defines named build configurations (development, production, and any custom ones like staging) under the configurations key of the build target. Each configuration can override settings such as optimization, source maps, and file replacements—commonly used to swap in an environment-specific environment.ts file containing API base URLs or feature flags. Running ng build --configuration=production (the default when just running ng build in modern CLI versions) applies these settings, while ng build --configuration=staging would apply a staging-specific override set.

🏏

Cricket analogy: Named build configurations are like a team having separate playing XIs for T20 finals versus a Ranji Trophy warm-up match, each swapping in different personnel (environment.ts) while running the same core game plan.

typescript

// angular.json (excerpt)
{
  "configurations": {
    "production": {
      "budgets": [
        { "type": "initial", "maximumWarning": "500kb", "maximumError": "1mb" },
        { "type": "anyComponentStyle", "maximumWarning": "4kb", "maximumError": "8kb" }
      ],
      "outputHashing": "all",
      "fileReplacements": [
        {
          "replace": "src/environments/environment.ts",
          "with": "src/environments/environment.prod.ts"
        }
      ]
    },
    "staging": {
      "fileReplacements": [
        {
          "replace": "src/environments/environment.ts",
          "with": "src/environments/environment.staging.ts"
        }
      ]
    }
  }
}

// Command examples
// ng build --configuration=production
// ng build --configuration=staging

Budgets, Lazy Loading, and Bundle Size

Build budgets, configured under each configuration's budgets array, cause the CLI to emit warnings or errors when the initial bundle or individual component styles exceed set thresholds—an early warning system against unnoticed bundle bloat. Combined with route-level lazy loading via loadComponent() or loadChildren(), budgets help teams keep the critical initial JavaScript payload small, since only the code needed for the initially rendered route is downloaded up front.

🏏

Cricket analogy: Build budgets are like a team's fielding coach flagging when the over rate falls behind schedule, giving an early warning before the match runs into overtime penalties, just as bundle-size warnings catch bloat before shipping.

Deployment Targets

Because ng build outputs static files (by default into dist/<project-name>/browser), an Angular app can be deployed to any static hosting provider—Netlify, Vercel, GitHub Pages, an S3 bucket behind CloudFront, or a plain Nginx container. For routed applications using the default PathLocationStrategy, the server must be configured to redirect all unmatched paths back to index.html so client-side routing can take over; without this rewrite rule, refreshing a deep link like /products/42 returns a 404 from the server instead of letting Angular's router handle it. Angular also supports Server-Side Rendering (SSR) via ng add @angular/ssr, which pre-renders pages on a Node server (or at build time via prerendering) for faster first paint and better SEO.

🏏

Cricket analogy: Deploying static files to any host is like a franchise being able to play its home games at any stadium with turf pitches, but the ground staff must add a specific 'DRS review' rule (rewrite rule) or a referred boundary call gets wrongly given out, like a 404 on /products/42.

Angular's build system is powered by esbuild in current CLI versions, replacing the older Webpack-based builder for most new projects. This dramatically speeds up both development rebuilds and production builds compared to Angular versions before the esbuild-based application builder became the default.

A frequent deployment mistake is forgetting the SPA fallback/rewrite rule on the hosting server. Without it, any direct navigation or page refresh on a non-root route returns the host's default 404 page instead of the Angular app, because the server has no file at that literal path.

ng build produces optimized, AOT-compiled static assets, typically in dist/<project-name>/browser.
angular.json build configurations (development, production, custom ones like staging) control optimization, source maps, and environment file replacements.
Build budgets warn or error when bundle sizes exceed configured thresholds, catching bloat before it ships.
Route-level lazy loading (loadComponent/loadChildren) keeps the initial bundle small by deferring code for routes not yet visited.
Static hosts serving a routed Angular app need a fallback rewrite rule sending unmatched paths to index.html.
ng add @angular/ssr enables server-side rendering or prerendering for faster first paint and improved SEO.

Practice what you learned

1. What compilation strategy does `ng build` use by default for production builds?

2. What is the purpose of `fileReplacements` in an angular.json build configuration?

3. What happens when a build exceeds the `maximumError` threshold in a budgets entry?

4. Why must a static host serving a routed Angular SPA redirect unmatched paths to index.html?

5. What does `ng add @angular/ssr` enable?

Was this page helpful?

Standalone Components and Bootstrapping

Related Study Notes in Web Development

Browse all study notes

Web Development

WebSockets Study Notes

Web Development · 30 topics

Web Development

WebAssembly Study Notes

WebAssembly · 30 topics

Web Development

gRPC Study Notes

Protocol Buffers · 30 topics

Web Development

Spring Boot Study Notes

Java · 30 topics

Web Development

Flask Study Notes

Python · 30 topics

Web Development

Django Study Notes

Python · 30 topics

Topics covered

#TypeScript#AngularStudyNotes#WebDevelopment#BuildingAndDeployingAnAngularApp#Building#Deploying#Angular#App#StudyNotes#SkillVeris

Building and Deploying an Angular App