Learn Angular - Modern Tooling & Build Automation

#Introduction

Good code needs good process. Automating build, lint, test, and release lets teams focus on the product, not on repetitive manual work.

Episode 19 covers the Angular CLI, builders, and custom schematics, a build pipeline with linting and formatting, continuous integration for Angular applications, and reproducible builds and release management. You'll see how an Angular project is produced from commit to release.

#Angular CLI, Builders, and Custom Schematics

#Builders: The Engine Behind the Commands

Commands like ng build and ng serve are doorways to builders — packages that do the actual work. A builder is described in angular.json:

{
  "builder": "@angular-devkit/build-angular:application",
  "options": {
    "outputPath": "dist/toko-online",
    "index": "src/index.html",
    "main": "src/main.ts"
  }
}

@angular-devkit/build-angular:application is the official builder for modern standalone applications. You can use builders from the ecosystem for special needs, or write your own.

#Custom Schematics

A schematic is a code generator run by the CLI. ng generate component internally invokes a schematic. Teams can create custom schematics so every generated file follows team standards — for example components that automatically include tests, OnPush, and a specific format.

ng generate @myorg/schematics:module-auth --dry-run

--dry-run shows which files would be created without actually creating them. Custom schematics spread team practices automatically — consistency without relying on memory.

#Build Pipeline, Linting, and Formatting

#Scripts in package.json

Standardize commands via scripts in package.json:

{
  "scripts": {
    "build": "ng build --configuration=production",
    "lint": "ng lint",
    "test": "ng test --watch=false --browsers=ChromeHeadless",
    "format": "prettier --write ."
  }
}

With these scripts, every person and every system uses the same commands. test uses ChromeHeadless so it can run in CI without a graphical browser.

#Lint and Format in CI

Run lint and format before the build in CI so problems are detected earlier:

npm run lint
npx prettier --check .
npm run test
npm run build

prettier --check . verifies formatting without writing — CI only passes if the formatting is consistent. Lint, format, test, then build: that's the standard quality gate before merge.

#Continuous Integration for Angular Apps

#A GitHub Actions Workflow

GitHub Actions runs the entire quality gate for every pull request:

name: CI Angular
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run test
      - run: npm run build

npm ci installs dependencies deterministically according to the lockfile. The Node cache speeds up installation. This workflow gives a fast signal on every PR: green means safe to merge, red means something needs fixing.

#Storing Artifacts

After the build, save the result as an artifact so it can be deployed or analyzed:

- uses: actions/upload-artifact@v4
  with:
    name: dist
    path: dist/toko-online

upload-artifact stores the dist folder so a later job — for example deployment — can use the same artifact. This also preserves reproducibility: the build result doesn't depend on a developer's machine.

#Reproducible Builds and Release Management

#The Keys to Reproducibility

A reproducible build always produces the same output from the same input. The keys: npm ci from the lockfile, pin the Node version with .nvmrc or engines, and avoid code that depends on time or environment.

{
  "engines": {
    "node": ">=20.19.0 <23"
  }
}

Declaring engines ensures everyone and CI use the same Node range. Different versions can produce different bundles — and bugs that only appear on certain machines.

#Semantic Release

Automated release management uses semantic-release: versioning follows conventional commits, the changelog is generated automatically, and versions are published according to the type of change.

npx semantic-release

npx semantic-release analyzes commits since the last release, determines the next version, updates the changelog, and creates the tag and release on GitHub. This practice eliminates manual version decisions and ensures every change is documented.

#Wrap Up

Key takeaways:

• Builders in angular.json are the engine behind CLI commands.
• Custom schematics standardize team-generated code.
• Standardize build, lint, test, and format scripts in package.json.
• CI runs the quality gate on every pull request.
• npm ci and pinning the Node version make builds reproducible.
• Semantic release automates versioning and changelogs.

In the next episode, episode 20, we'll cover deployment and hosting — deployment options on Firebase, Vercel, Netlify, and AWS, server-side rendering with Angular Universal, static site generation and prerendering, and production deployment best practices.