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 1 of 2

With the Angular CLI, how does `ng serve` differ from `ng build`, and why is the dev server's output never what you deploy?

juniormust knowfreq 70%

answer

two builders, one build pipeline
@angular/build:dev-server wraps application
development vs production configuration
in memory, watched, served by Vite
dist/<project>/browser is the artifact

basics

~20 s

ng serve runs the @angular/build:dev-server builder, which builds the app with its development configuration in memory, watches files and reloads the browser. ng build runs @angular/build:application with the production configuration and writes optimized, hashed files to dist/<project>/browser for deployment.

solid answer

~40 s

Both commands build the application with the same @angular/build:application pipeline, but for different purposes. ng build (alias ng b) runs the build target, whose defaultConfiguration is production in a new project: optimization on, no source maps, outputHashing: 'all', licenses extracted. It writes to dist/<project>/browser (plus server when SSR is on), and that folder is the deployable artifact. ng serve (aliases ng s, ng dev) runs the serve target's @angular/build:dev-server builder. It points at build:development by default, which turns optimization off and source maps on. It keeps the output in memory, hands it to a Vite-based server, rebuilds only what changed on each save, and reloads or hot-replaces in the browser. It is unminified, unhashed and not written to dist, so it is a development tool, never a deployment.

Both commands build the application with the same `@angular/build:application` pipeline, but for different purposes. `ng build` (alias `ng b`) runs the `build` target, whose `defaultConfiguration` is `production` in a new project: optimization on, no source maps, `outputHashing: 'all'`, licenses extracted. It writes to `dist/<project>/browser` (plus `server` when SSR is on), and that folder is the deployable artifact. `ng serve` (aliases `ng s`, `ng dev`) runs the `serve` target's `@angular/build:dev-server` builder. It points at `build:development` by default, which turns optimization off and source maps on. It keeps the output in memory, hands it to a Vite-based server, rebuilds only what changed on each save, and reloads or hot-replaces in the browser. It is unminified, unhashed and not written to `dist`, so it is a development tool, never a deployment.

code

json · 16 lines

json

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

go deeper

for a junior

Know that ng serve is for local development with reload on save, and ng build creates the production files in dist to deploy.

for a middle

Explain the build and serve targets, the dev-server's buildTarget, and exactly which options the production and development configurations change.

for a senior

Use ng serve --configuration production to reproduce production-only bugs, knowing what changes (HMR off, optimized code), and keep CI deploying only ng build artifacts.

for a principal

Standardise how every app in the organisation builds and serves, so local, CI and production share one configuration model and differences are deliberate.

Two targets, two builders

In angular.json every command maps to a target that names a builder, the function that does the work. A project created by Angular CLI 22 has:

Target	Builder	`defaultConfiguration`	Used by
`build`	`@angular/build:application`	`production`	`ng build` / `ng b`
`serve`	`@angular/build:dev-server`	`development`	`ng serve` / `ng s` / `ng dev`

The dev-server builder does not have its own compiler. Its buildTarget option points at the build target with a configuration: app:build:development by default, app:build:production when you run ng serve --configuration production. It then runs that same application build internally.

What the two configurations change

The generated build target keeps most values at the builder's schema defaults and overrides a few per configuration:

production: outputHashing: 'all' and the budgets. Everything else uses the schema defaults, so optimization is true, sourceMap is false, extractLicenses is true and namedChunks is false.
development: optimization: false, extractLicenses: false, sourceMap: true, with outputHashing left at its default of none.

So ng build gives minified, tree-shaken, cache-busted files with a separate license file. ng serve gives readable code with source maps, which is fast to rebuild and easy to debug.

What `ng serve` does on top

Builds in memory. The Angular docs describe the dev server as generating a development build in memory and passing the results to Vite to serve. Vite is used here only as a development server and cannot be configured directly. Nothing is written to dist/.
Watches and rebuilds incrementally. watch defaults to true. On save, only affected files are recompiled.
Updates the browser. liveReload defaults to true. Style and template edits are hot-replaced (HMR) where possible; other changes trigger a full page reload.
Prebundles dependencies. Third-party packages are processed once on first start, so later rebuilds skip them. The prebundle option controls it.
Serves on a local address. By default it serves on localhost port 4200. Host, port, HTTPS and proxying to a backend are dev-server options too.

Why you never deploy the dev server

The output is unoptimized: no minification, no tree-shaking beyond what the bundler does by default, and large source maps.
File names are not content-hashed for entry bundles, so browsers and CDNs cannot cache them safely.
It exists only in the memory of a process built for fast rebuilds and debugging. It has development-only behaviour such as live reload and prebundling, and it is not designed or hardened to serve real traffic.
ng build produces a static folder that any web server or CDN can host (or a server bundle for SSR). That is what CI should build and ship.

Commands you actually type

bash

ng serve                      # development build, in memory, http://localhost:4200
ng serve --configuration production   # check production settings locally
ng build                      # production build into dist/<project>/browser
ng build --configuration development  # unminified build written to disk

ng serve --configuration production is handy for reproducing a production-only bug. Note that it serves the production build settings through the dev server, and that HMR turns itself off because of outputHashing: 'all'.

Side by side

Aspect	`ng serve`	`ng build`
Builder	`@angular/build:dev-server`	`@angular/build:application`
Default configuration	`development`	`production`
Output	In memory	`dist/<project>/browser` (and `server` for SSR)
Minified	No	Yes
Source maps	Yes	No
Hashed entry file names	No	Yes (`outputHashing: 'all'`)
Watches and reloads	Yes	No, unless `--watch`
Purpose	Local development	The deployable artifact

The table is a summary of the generated defaults. Every row can be changed per configuration, which is why teams sometimes add a staging configuration that serves or builds with production-like settings.

Common interview traps

Saying ng serve "uses Webpack". New projects have used the esbuild-based application builder since v17, taken directly from the @angular/build package since v20, and the webpack builders in @angular-devkit/build-angular are deprecated in v22.
Thinking ng build defaults to a development build. In generated projects defaultConfiguration is production.
Looking for the output in dist/<project> directly. The application builder writes browser files to a browser subfolder.

## Two targets, two builders In `angular.json` every command maps to a **target** that names a **builder**, the function that does the work. A project created by Angular CLI 22 has: | Target | Builder | `defaultConfiguration` | Used by | |---|---|---|---| | `build` | `@angular/build:application` | `production` | `ng build` / `ng b` | | `serve` | `@angular/build:dev-server` | `development` | `ng serve` / `ng s` / `ng dev` | The dev-server builder does not have its own compiler. Its `buildTarget` option points at the build target with a configuration: `app:build:development` by default, `app:build:production` when you run `ng serve --configuration production`. It then runs that same application build internally. ## What the two configurations change The generated `build` target keeps most values at the builder's schema defaults and overrides a few per configuration: - **production**: `outputHashing: 'all'` and the budgets. Everything else uses the schema defaults, so `optimization` is `true`, `sourceMap` is `false`, `extractLicenses` is `true` and `namedChunks` is `false`. - **development**: `optimization: false`, `extractLicenses: false`, `sourceMap: true`, with `outputHashing` left at its default of `none`. So `ng build` gives minified, tree-shaken, cache-busted files with a separate license file. `ng serve` gives readable code with source maps, which is fast to rebuild and easy to debug. ## What `ng serve` does on top 1. **Builds in memory.** The Angular docs describe the dev server as generating a development build in memory and passing the results to Vite to serve. Vite is used here *only* as a development server and cannot be configured directly. Nothing is written to `dist/`. 2. **Watches and rebuilds incrementally.** `watch` defaults to `true`. On save, only affected files are recompiled. 3. **Updates the browser.** `liveReload` defaults to `true`. Style and template edits are hot-replaced (HMR) where possible; other changes trigger a full page reload. 4. **Prebundles dependencies.** Third-party packages are processed once on first start, so later rebuilds skip them. The `prebundle` option controls it. 5. **Serves on a local address.** By default it serves on `localhost` port `4200`. Host, port, HTTPS and proxying to a backend are dev-server options too. ## Why you never deploy the dev server - The output is **unoptimized**: no minification, no tree-shaking beyond what the bundler does by default, and large source maps. - File names are **not content-hashed** for entry bundles, so browsers and CDNs cannot cache them safely. - It exists only **in the memory of a process** built for fast rebuilds and debugging. It has development-only behaviour such as live reload and prebundling, and it is not designed or hardened to serve real traffic. - `ng build` produces a **static folder** that any web server or CDN can host (or a server bundle for SSR). That is what CI should build and ship. ## Commands you actually type ```bash ng serve # development build, in memory, http://localhost:4200 ng serve --configuration production # check production settings locally ng build # production build into dist/<project>/browser ng build --configuration development # unminified build written to disk ``` `ng serve --configuration production` is handy for reproducing a production-only bug. Note that it serves the production build settings through the dev server, and that HMR turns itself off because of `outputHashing: 'all'`. ## Side by side | Aspect | `ng serve` | `ng build` | |---|---|---| | Builder | `@angular/build:dev-server` | `@angular/build:application` | | Default configuration | `development` | `production` | | Output | In memory | `dist/<project>/browser` (and `server` for SSR) | | Minified | No | Yes | | Source maps | Yes | No | | Hashed entry file names | No | Yes (`outputHashing: 'all'`) | | Watches and reloads | Yes | No, unless `--watch` | | Purpose | Local development | The deployable artifact | The table is a summary of the *generated* defaults. Every row can be changed per configuration, which is why teams sometimes add a `staging` configuration that serves or builds with production-like settings. ## Common interview traps - Saying `ng serve` "uses Webpack". New projects have used the esbuild-based application builder since v17, taken directly from the `@angular/build` package since v20, and the webpack builders in `@angular-devkit/build-angular` are deprecated in v22. - Thinking `ng build` defaults to a development build. In generated projects `defaultConfiguration` is `production`. - Looking for the output in `dist/<project>` directly. The application builder writes browser files to a `browser` subfolder.

Where does `ng build` put its output, and why did that surprise teams moving from the old builder?
By default the application builder writes to `dist/<project>/browser`, plus `dist/<project>/server` when SSR is enabled. The old `browser` builder wrote straight into `dist/<project>`, so deploy scripts that copied that folder broke. Adjust the scripts, or configure `outputPath` so the browser folder name is empty.
Why might `ng serve` show a brief flash of unstyled content that `ng build` output never shows?
The dev server defers processing stylesheets until they are first used, to keep rebuilds fast. The Angular docs note this can cause a small flash of unstyled content on startup. It does not happen in builds outside the dev server.

saying these in an interview costs you the question

Deploys the output of ng serve or copies files out of the dev server
Believes ng build produces a development build unless --prod is passed
Says ng serve in a new project runs a webpack dev server
Expects the built browser files directly in dist/<project> with the application builder
Thinks ng serve has its own compiler separate from the application builder

§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

With the Angular CLI, how does `ng serve` differ from `ng build`, and why is the dev server's output never what you deploy?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two targets, two builders

What the two configurations change

What ng serve does on top

Why you never deploy the dev server

Commands you actually type

Side by side

Common interview traps

▾common follow-ups2 questions

▾red flags5 flags

With the Angular CLI, what does `ng generate library` add to a workspace, and what must happen before an app in that workspace can import it?

basics

With the Angular CLI, what does `ng generate component` create in a v22 project, and how do you preview it before any file is written?

basics

With the Angular CLI's `ng serve`, how do you forward `/api` requests to a backend running locally on another port, and why does that not help in production?

basics

With the Angular CLI, what does `ng update @angular/core @angular/cli` do beyond changing version numbers in package.json?

basics

With the Angular CLI, why does ng build produce an optimized, hashed bundle while ng serve does not, in a newly generated angular.json?

basics

In Angular's application builder, what do `optimization`, `sourceMap`, `outputHashing` and `namedChunks` control, and how do production and development builds set them?

basics

In an Angular CLI library project, why does the production build set `compilationMode` to `partial`, and what goes wrong if you publish a development build?

basics

With the Angular CLI, what does `ng add <package>` do that a plain `npm install <package>` does not?

basics

Why does the Angular CLI refuse to update `@angular/core` from v20 straight to v22, and how do you move an app across several majors?

basics

In an Angular CLI project, how do you add a staging build configuration with its own environment file, and what does fileReplacements do?

basics

What do the Angular CLI's `ng serve` options `host`, `port` and `ssl` control, and what do you change to open the dev server from another device?

basics

With the Angular CLI dev server, which edits are hot-replaced without a page reload, which cause a full reload, and what can switch HMR off?

basics

How do you give an error-reporting service readable stack traces for an Angular CLI production build without letting browsers download your source maps?

basics

In an Angular CLI library, what is `public-api.ts` for, and how does `ng-package.json` connect it to what consuming apps can import?

basics

In an Angular CLI workspace, how do you make every `ng generate component` default to SCSS and no spec file, and which setting wins?

basics

In Angular schematics, what is the virtual `Tree`, and why does a schematic that throws halfway leave every file on disk unchanged?

basics

In an Angular CLI 22 application build, what does `outputMode: 'static'` versus `'server'` change in what `ng build` produces and how you deploy it?

basics

With the Angular CLI, when do you run `ng update <package> --migrate-only --from <version>`, and how does it differ from a normal `ng update`?

basics

In angular.json, which budget types can the Angular CLI enforce, and how do maximumWarning, maximumError and baseline decide whether a build fails?

basics

In a multi-project Angular CLI workspace, how does ng build decide which project to build, and how do you target one explicitly?

basics

An Angular app still builds with `@angular-devkit/build-angular:browser`; how do you migrate it to the application builder, and what breaks along the way?

basics

When a new release of your internal Angular UI-kit library makes one app fail to build and another throw injection errors, what do you check and fix?

basics

guide

primer

explore

questions

answer

go deeper

What `ng serve` does on top

What `ng serve` does on top