Angular CLI

2 roadmaps 32 questionsupdated 2026-09-29

The ng tool scaffolds, builds, serves, tests and updates Angular workspaces through angular.json targets, schematics and builders. Interviewers ask because Angular build questions land here.

▸ follow the angular roadmap jump to the questions →

on this pageshow

guide

overview

~1 min

The Angular CLI is the ng command that creates, builds, serves, tests, generates code in and upgrades Angular workspaces. Most practical Angular build questions land here, because the CLI owns the build: an interviewer who asks why a staging bundle ships unhashed, why a deep link 404s under a sub-path, or why an upgrade stalls on a peer dependency is asking how the CLI turns configuration into output. A good answer names the option that decides the behaviour, not only the command typed.

The hub follows the life of a workspace. Workspace file and targets covers angular.json, the map every command reads. Builders and dev server is what actually runs when you build or serve, and serve, proxy and deploy is how that output meets a backend and a host. Generators and schematics is the code-writing side, update command and migrations reuses the same machinery to move an app across majors, and library projects is how a team shares code between apps.

Junior rounds check everyday commands and why ng serve output is not what you deploy. Middle rounds move into configurations, budgets, source maps and generator defaults. Senior rounds are migration and incident stories: a multi-major upgrade, a library release that breaks consumers, a builder swap.

Start with the workspace file, since every other section refers to its targets, then builders, then schematics; updates and libraries make sense only after those three.

The Angular CLI is the `ng` command that creates, builds, serves, tests, generates code in and upgrades Angular workspaces. Most practical Angular build questions land here, because the CLI owns the build: an interviewer who asks why a staging bundle ships unhashed, why a deep link 404s under a sub-path, or why an upgrade stalls on a peer dependency is asking how the CLI turns configuration into output. A good answer names the option that decides the behaviour, not only the command typed. The hub follows the life of a workspace. [Workspace file and targets](/topics/fe-angular-cli-workspace) covers `angular.json`, the map every command reads. [Builders and dev server](/topics/fe-angular-cli-build-system) is what actually runs when you build or serve, and [serve, proxy and deploy](/topics/fe-angular-cli-serve-deploy) is how that output meets a backend and a host. [Generators and schematics](/topics/fe-angular-cli-schematics) is the code-writing side, [update command and migrations](/topics/fe-angular-cli-update) reuses the same machinery to move an app across majors, and [library projects](/topics/fe-angular-cli-libraries) is how a team shares code between apps. Junior rounds check everyday commands and why `ng serve` output is not what you deploy. Middle rounds move into configurations, budgets, source maps and generator defaults. Senior rounds are migration and incident stories: a multi-major upgrade, a library release that breaks consumers, a builder swap. Start with the workspace file, since every other section refers to its targets, then builders, then schematics; updates and libraries make sense only after those three.

primer

Every command resolves to a target

ng build, ng serve, ng test and ng deploy are shortcuts. Each picks a project, looks up a named target in angular.json, and hands that target's options to a builder. Knowing that a command is really a project, a target and a configuration explains most build surprises and how to fix them without touching the command itself.

Configurations are named overrides

A target holds base options plus named configurations such as production and development, and one of them is the default. Environments, file swaps and budgets live there. How configurations combine, and what you lose when you name one explicitly, is a favourite middle-level trap.

Builders do the work, the CLI only dispatches

The build, the dev server, the test runner and the library packager are all builders: packages that implement a target. The CLI ships the common ones and third parties ship the rest, so ng deploy does nothing until something installs a deploy builder. Swapping a builder changes what a build emits, which is why builder migrations are senior material.

Schematics write code through a staging area

ng generate, ng add and update migrations are schematics: functions that describe file changes against an in-memory copy of the workspace, committed only when the whole run succeeds. That one mechanism serves scaffolding, library installation, team conventions and automated upgrades.

Upgrades are migrations, not version bumps

ng update pairs a dependency change with the code changes that change requires, and it deliberately moves @angular/* one major at a time. Peer dependency checks and a clean working tree are part of the safety story interviewers expect you to tell.

Libraries ship for someone else's compiler

A library project is compiled for publishing rather than for running, and the consuming app finishes the job. Its public surface, its peer dependencies and the Angular release it was compiled against decide whether consumers can use it.

### Every command resolves to a target `ng build`, `ng serve`, `ng test` and `ng deploy` are shortcuts. Each picks a project, looks up a named **target** in `angular.json`, and hands that target's options to a **builder**. Knowing that a command is really a project, a target and a configuration explains most build surprises and how to fix them without touching the command itself. ### Configurations are named overrides A target holds base options plus named **configurations** such as production and development, and one of them is the default. Environments, file swaps and budgets live there. How configurations combine, and what you lose when you name one explicitly, is a favourite middle-level trap. ### Builders do the work, the CLI only dispatches The build, the dev server, the test runner and the library packager are all builders: packages that implement a target. The CLI ships the common ones and third parties ship the rest, so `ng deploy` does nothing until something installs a deploy builder. Swapping a builder changes what a build emits, which is why builder migrations are senior material. ### Schematics write code through a staging area `ng generate`, `ng add` and update migrations are **schematics**: functions that describe file changes against an in-memory copy of the workspace, committed only when the whole run succeeds. That one mechanism serves scaffolding, library installation, team conventions and automated upgrades. ### Upgrades are migrations, not version bumps `ng update` pairs a dependency change with the code changes that change requires, and it deliberately moves `@angular/*` one major at a time. Peer dependency checks and a clean working tree are part of the safety story interviewers expect you to tell. ### Libraries ship for someone else's compiler A library project is compiled for publishing rather than for running, and the consuming app finishes the job. Its public surface, its peer dependencies and the Angular release it was compiled against decide whether consumers can use it.

angular.json: The workspace configuration file. It lists each project, its targets with their builders and options, and workspace-wide CLI and generator settings.
Target: A named task on a project, such as build, serve, test or deploy, bound to one builder and its options. ng run project:target runs it.
Build configuration: A named set of option overrides inside a target, selected with -c or by defaultConfiguration, used for environments such as production and development.
fileReplacements: A build option that swaps one source file for another at compile time, the usual way to give each configuration its own environment file.
Builder: A package function that executes a target with its options and reports success or failure. Builds, the dev server, tests and deploys are all builders.
Application builder: The esbuild-based builder that bundles browser code and, when enabled, server code for prerendering and server-side rendering; the default for new applications.
Schematic: A code generator: a function returning a Rule that transforms the workspace. ng generate, ng add and update migrations all run schematics.
Virtual Tree: The in-memory view of the workspace a schematic edits. Changes are staged there and written to disk only if the whole schematic succeeds.
Budget: A size threshold set on a build configuration. Crossing its warning level logs a warning; crossing its error level fails the build.
ng-packagr: The tool that builds Angular library projects into publishable packages in the Angular Package Format.
Partial compilation: The library compilation mode that emits Angular code independent of an exact Angular runtime version, leaving the final step to the consuming app's build.

Read angular.json as a routing table. Each project lists targets; each target names a builder, base options, named configurations and a default. A command like ng build picks the project, looks up the target, merges the chosen configuration over the base options and runs the builder. The dev server does not build on its own: its configurations point back at the build target, so serving and building share one set of source options and differ only in the configuration each picks.

json

"storefront": {
  "architect": {
    "build": {
      "builder": "@angular/build:application",
      "configurations": { "production": { "outputHashing": "all" }, "development": { "optimization": false } },
      "defaultConfiguration": "production"
    },
    "serve": {
      "builder": "@angular/build:dev-server",
      "configurations": { "development": { "buildTarget": "storefront:build:development" } },
      "defaultConfiguration": "development"
    }
  }
}

The other sections hang off the same file:

Generators write through a virtual tree and read their defaults from the workspace's schematics settings, so conventions live next to targets.
Updates change package versions, then run migration schematics that edit source files and angular.json itself.
Libraries are projects whose build target runs ng-packagr instead of the application builder; apps consume the built output, not the source.
Serve, proxy and deploy come down to dev-server options plus a deploy target whose builder a hosting package supplies.

Most interview incidents sit at a seam between two of these: a configuration that skips a production option, a library built with the wrong mode, an upgrade that left a builder untouched.

Read `angular.json` as a routing table. Each project lists targets; each target names a builder, base options, named configurations and a default. A command like `ng build` picks the project, looks up the target, merges the chosen configuration over the base options and runs the builder. The dev server does not build on its own: its configurations point back at the build target, so serving and building share one set of source options and differ only in the configuration each picks. ```json "storefront": { "architect": { "build": { "builder": "@angular/build:application", "configurations": { "production": { "outputHashing": "all" }, "development": { "optimization": false } }, "defaultConfiguration": "production" }, "serve": { "builder": "@angular/build:dev-server", "configurations": { "development": { "buildTarget": "storefront:build:development" } }, "defaultConfiguration": "development" } } } ``` The other sections hang off the same file: - **Generators** write through a virtual tree and read their defaults from the workspace's schematics settings, so conventions live next to targets. - **Updates** change package versions, then run migration schematics that edit source files and `angular.json` itself. - **Libraries** are projects whose build target runs ng-packagr instead of the application builder; apps consume the built output, not the source. - **Serve, proxy and deploy** come down to dev-server options plus a deploy target whose builder a hosting package supplies. Most interview incidents sit at a seam between two of these: a configuration that skips a production option, a library built with the wrong mode, an upgrade that left a builder untouched.

Workspace File & Targets →
angular.json, targets and configurations: the map every command reads, and where most build surprises are decided.
Builders & Dev Server →
What ng build and ng serve actually run, which options shape production output, and how the dev server behaves.
Serve, Proxy & Deploy →
How built output meets a backend during development and a host in production: proxying, sub-path deployment and deploy targets.
Generators & Schematics →
How ng generate and ng add write code, and how teams encode their own conventions as schematics.
Update Command & Migrations →
Upgrades reuse schematics as migrations; this is where multi-major moves and peer dependency conflicts are handled.
Library Projects →
Sharing code across apps: library builds, public API surface and why the compilation mode matters to consumers.

Deploying what ng serve produced, or benchmarking it: the dev server builds with the development configuration, in memory, without production optimizations.
Assuming a named configuration stacks on the default one: -c staging alone drops production settings unless staging repeats them or you list both.
Treating ng add as npm install: it also runs the package's setup schematic, which may edit providers, styles and angular.json.
Jumping several Angular majors in one ng update, or reaching for --force on a peer conflict before proving the blocking library works on the new version.
Publishing a library from a development build or with @angular/* as regular dependencies, which breaks consumers on other versions or gives them two Angular copies.
Expecting the dev-server proxy to exist in production; it is read only by ng serve, so production needs a reverse proxy or CORS.
Fixing a sub-path deployment with deployUrl alone; the base href and the server's fallback to index.html decide whether deep links resolve — see sub-path deployment.

Angular 17 made the esbuild-based application builder, with a Vite-powered dev server, the default for new applications. Older workspaces may still build with the webpack-based browser builder until someone migrates them, and that migration changes the output folder layout.
Angular 18 moved the application builder and dev server into the separate @angular/build package, so builder names in angular.json differ between workspaces generated before and after.
Angular 19 added outputMode, which decides whether a build emits only static files or a server bundle as well.
Angular 20 adopted an updated style guide, so generated component files and classes drop the .component and Component suffixes.

When an answer relies on builder names, output paths or generated file names, say which version you mean; a workspace upgraded with ng update can carry an older layout than a freshly generated one.

This guide assumes Angular CLI 22, the version the questions below are written against. Several answers depend on the era a workspace was created in, and interviewers who maintain older apps will probe the differences: - **Angular 17** made the esbuild-based application builder, with a Vite-powered dev server, the default for new applications. Older workspaces may still build with the webpack-based browser builder until someone migrates them, and that migration changes the output folder layout. - **Angular 18** moved the application builder and dev server into the separate `@angular/build` package, so builder names in `angular.json` differ between workspaces generated before and after. - **Angular 19** added `outputMode`, which decides whether a build emits only static files or a server bundle as well. - **Angular 20** adopted an updated style guide, so generated component files and classes drop the `.component` and `Component` suffixes. When an answer relies on builder names, output paths or generated file names, say which version you mean; a workspace upgraded with `ng update` can carry an older layout than a freshly generated one.

explore

report an issue with this guide →

questions

page 2 of 2

In an Angular CLI library built with ng-packagr, how do you add a secondary entry point such as `ui-kit/testing`, and when is one worth it?

seniornice to knowfreq 30%

basics

~20 s

A secondary entry point is a library subfolder with its own ng-package.json naming an entry file; the same ng build packages it as a separate import path like ui-kit/testing. Use one for optional code, heavy dependencies or test helpers.

open as a page

As an Angular library author, how do you ship a migration schematic so `ng update` rewrites consumers' code for your breaking change?

seniornice to knowfreq 18%

basics

~20 s

Point ng-update.migrations in the library's package.json at a migration collection whose entries each carry a version, a factory and a description. When a consumer updates across that version, ng update runs the rule, which edits their code through the Tree.

open as a page

showing 31–32 of 32

§guide

overview

§primer

▾core ideas~2 min

Every command resolves to a target

Configurations are named overrides

Builders do the work, the CLI only dispatches

Schematics write code through a staging area

Upgrades are migrations, not version bumps

Libraries ship for someone else's compiler

▾vocabulary11 terms

▾how it fits~1 min

▾where to start6 steps

▾common pitfalls7

▾versions4

§explore

▾sections6 · 32 questions

▾roadmaps that cover this2

§questions

In an Angular CLI library built with ng-packagr, how do you add a secondary entry point such as `ui-kit/testing`, and when is one worth it?

basics

As an Angular library author, how do you ship a migration schematic so `ng update` rewrites consumers' code for your breaking change?

basics

Every command resolves to a target

Configurations are named overrides

Builders do the work, the CLI only dispatches

Schematics write code through a staging area

Upgrades are migrations, not version bumps

Libraries ship for someone else's compiler

guide

primer

explore

questions