Angular CLI Guide: ng new, ng update, Multiple Apps and Multiple Angular Versions

Angular Tutorial: Beginner to Advanced · 2. Your first app · 4 min read · Updated

The Angular CLI (ng) creates, builds, tests and upgrades your project. You met it in the first lessons. Here are the parts you will need as a project grows.

What you will learn

  • ng new and its useful options
  • Checking the CLI and project versions
  • Upgrading safely with ng update
  • More than one app in a single workspace
  • Working on projects that use different Angular or Node versions

ng new

ng new my-shop                      # asks a few questions
ng new my-shop --style=scss --ssr   # skip the questions for these choices
ng new my-shop --skip-git --skip-install   # no git repo and no npm install yet

Useful options: --style (css, scss, sass, less), --ssr (server-side rendering), --skip-git, --skip-install, --skip-tests, --package-manager (npm, pnpm, yarn). Run ng new --help to see them all for your version.

Daily commands:

  • `ng serve`: What it does: Dev server with live reload
  • `ng build`: What it does: Production build into dist/
  • `ng test`: What it does: Runs unit tests
  • `ng generate component x` (or `ng g c x`): What it does: Creates files from a schematic
  • `ng add <package>`: What it does: Installs a package and configures it (@angular/ssr, @angular/material)
  • `ng update`: What it does: Upgrades Angular and runs migrations

Which version am I using?

ng version     # CLI, Angular, Node and package versions for this project
ng --version   # same
node --version

Run it inside the project. A global CLI and the local CLI in node_modules may differ. Inside a project, ng uses the local one when it exists, so the project's version wins.

Upgrading with ng update

Upgrade one major version at a time. Angular gives a step by step checklist at update.angular.dev. The usual flow:

git status                 # start with a clean working tree
ng update                  # lists what can be updated
ng update @angular/core@NEXT_MAJOR @angular/cli@NEXT_MAJOR

Replace NEXT_MAJOR with the next major number (for example from 21 to 22, write 22). The command updates the packages and runs migrations that rewrite your code for removed or changed APIs. Then:

  1. Run ng build and ng test.
  2. Read the warnings, and fix deprecations (for example move from *ngIf to @if).
  3. Commit, then repeat for the next major version.

Never skip several majors in one jump. If a migration fails, fix the error, and run the remaining migration with ng update @angular/core --migrate-only --from=<old> --to=<new>.

Many apps in one workspace

One repository can hold several apps and libraries that share code. A workspace has one angular.json with a projects section.

ng new workspace --no-create-application   # an empty workspace
cd workspace
ng generate application admin-site
ng generate application public-site
ng generate library ui-kit                 # shared components

Run them by name:

ng serve admin-site
ng build public-site
ng test ui-kit

Apps live in projects/<name>/src. Shared code goes into a library that both apps import. If you only have one app, you do not need this.

You can also add a second app to an existing project with ng generate application second-app.

Different projects, different versions

Your laptop may hold a project on Angular 18 and another on Angular 22. Rules to avoid trouble:

  • Never rely on the global CLI. Use the local one: npx ng build, or npm run build (scripts use the local CLI).
  • Create a project with a specific version without installing it: npx @angular/cli@21 new old-app.
  • Each Angular version needs a range of Node versions. Check the compatibility table in the Angular docs ("Version compatibility").
  • Switch Node versions per project with a version manager such as nvm, fnm or Volta. Put a .nvmrc file in the project:
echo "24" > .nvmrc
nvm use          # reads .nvmrc
  • Record the Node range in package.json under "engines" so the team gets a warning when it is wrong.
  • Keep each project in its own folder with its own node_modules. Never share one node_modules between projects.

Common mistakes

  • Running ng update with uncommitted changes, so you cannot see what the migration did.
  • Jumping across many major versions at once.
  • Using the global ng and being surprised by a different version.
  • Mixing package managers (package-lock.json and pnpm-lock.yaml in one project).

Try it yourself

  1. Run ng version and write down the Angular and Node versions.
  2. Create an empty workspace and add two applications and one library.
  3. Add a .nvmrc file to a project and switch Node with it.

Quick check

  1. Which command shows the Angular version of a project?
  2. Why upgrade one major version at a time?
  3. How do you run a specific app in a workspace?

Next, continue with Displaying Data in Angular with Interpolation.

Frequently asked questions

Should I install the Angular CLI globally?

You can, to run ng new. For everything else the project's local CLI is used. Prefer npx @angular/cli new my-app so you never depend on a global version.

How often should I upgrade Angular?

Angular ships a major version about every six months. Staying within one or two versions of the latest keeps upgrades small and secure.