skip to content

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

level: middleimportance: must knowfreq 55%

answer

  1. install plus configure
  2. a compatible version, checked against peers
  3. the package's ng-add schematic
  4. package.json schematics field
  5. ng-add.save decides where it is saved

basics

~20 s

ng add picks a version compatible with the workspace's installed packages, installs it, then runs the package's own ng-add schematic to wire it in: providers, config, styles, angular.json targets. npm install only downloads the package.

solid answer

~40 s

`npm install` downloads a package and records it; the project is unchanged otherwise. `ng add <package>` does three things. It resolves a version: it tries the package's `latest` tag and, if that version's peer dependencies conflict with what is installed, searches for the newest compatible one. It asks for confirmation and installs it, into `dependencies`, `devDependencies` or a temporary location, depending on the package's `ng-add.save` field. Then it runs the package's `ng-add` schematic, found through the `schematics` field of the package's `package.json`, which can add providers to `app.config.ts`, update `angular.json`, add styles or install more dependencies. A package with no `ng-add` schematic is simply installed. `--dry-run` shows what would happen, and `--skip-confirmation` skips the prompt.

code

bash · 3 lines
bash
ng add @angular/pwa --dry-run        # report what would happen
ng add @angular/pwa --project admin  # run its ng-add schematic for one project
ng add @angular/localize --skip-confirmation

go deeper

for a junior

Know that ng add installs a library and then configures the project for it, while npm install only downloads it.

for a middle

Explain the stages: peer-compatible version resolution, install governed by ng-add.save, then the package's ng-add schematic found via its schematics field.

for a senior

Treat ng add as an automated code change: dry-run it, review the diff, pass schematic options per project, and diagnose peer-dependency version failures.

for a principal

When your team ships an internal library, decide whether an ng-add schematic is worth maintaining versus a written setup guide, weighing adoption speed against upkeep.

## Two commands, two jobs `npm install some-lib` (or the pnpm/yarn/bun equivalent) resolves a version, downloads it into `node_modules` and records it in `package.json`. Nothing in your Angular code or configuration changes. You then read the library's setup guide and wire it in by hand: register providers, import styles, add an `angular.json` option. `ng add some-lib` is the Angular CLI's **install-and-configure** command. It belongs to the same family as `ng generate`: it installs a package, then runs a schematic that the library author wrote to perform that setup for you. ## What `ng add` does, step by step 1. **Resolve a compatible version.** Unless you pin one (`ng add [email protected]`), the CLI fetches the package's `latest` version. It checks that version's peer dependencies against the packages already installed. If they conflict, it searches older releases for the newest compatible one and reports the conflicts when none fits. Prereleases are skipped unless the CLI itself is a prerelease. 2. **Confirm.** It shows the package and version and asks before installing and executing it. `--skip-confirmation` bypasses the prompt, which is useful in scripts once you are sure of the name. 3. **Install.** Where the package is saved depends on the `ng-add` field in the library's `package.json`: - `"save": "dependencies"` saves it under `dependencies`; - `"save": "devDependencies"` saves it under `devDependencies`; - `"save": false` installs it only in a temporary location and cleans it up after the schematic has run. This suits a pure setup tool. 4. **Run the `ng-add` schematic.** The CLI opens the collection named by the package's `schematics` field and runs the schematic called `ng-add`. That schematic works on the same virtual tree as any other, so it can edit `app.config.ts`, add a target or option to `angular.json`, add stylesheet entries, or schedule a further package install. `ng add` may run an `ng-add` schematic marked private, which `ng generate` would refuse to run. 5. **No schematic, no setup.** If the package has no `ng-add` schematic, the CLI says the package was installed and no further actions were taken. In CLI 22.2 a few well-known packages without their own schematic, such as `tailwindcss` and the Vitest browser providers, are mapped to built-in schematics in `@schematics/angular` instead. ## Side by side | | `npm install x` | `ng add x` | |---|---|---| | Version choice | The `latest` tag, or the range you give | `latest`, or newest release whose peers fit the workspace | | Confirmation | None | Prompt, unless `--skip-confirmation` | | Where it is saved | `dependencies` (unless you pass a flag) | Chosen by the library's `ng-add.save` | | Project configuration | Untouched | Library's `ng-add` schematic edits code and config | | Preview | No | `--dry-run` reports what would happen | ## What an `ng-add` schematic typically does The library author writes the setup as ordinary schematic rules. `@schematics/angular/utility` gives them ready-made building blocks: - `addRootProvider(project, ...)` adds a provider call to the application's root configuration (`app.config.ts` in a standalone app); - `addRootImport(project, ...)` adds an import to the root of an NgModule-based app; - `updateWorkspace(...)` changes `angular.json`, for example adding a builder option or an asset; - `addDependency(name, version)` adds a further package and schedules the install. Because these run on the virtual tree, a failure halfway through leaves the project unchanged. ## Using it well - **Review the diff.** `ng add` edits your files. Commit before running it and read the resulting diff, as you would a teammate's change. - **Use `--dry-run` for unfamiliar packages.** In a dry run the CLI does not run the schematic's actions. It reports whether the package has `ng add` actions and says they would be executed next. - **Pass schematic options.** Anything the library's `ng-add` schema declares becomes a flag, for example `--project admin` in a multi-project workspace. Leaving out a prompted option triggers an interactive question. - **Know what `ng add` is not.** It is not an upgrade tool: moving an installed library to a new major version and running its migrations is `ng update`'s job. ## Why interviewers ask The question checks whether a candidate sees the CLI as more than a build runner. A good answer names the three stages (compatible version, install, `ng-add` schematic). It knows that the library author, not the CLI, decides what gets configured. It treats the result as a code change to review, because it is one.

  • `ng add` reports that no compatible version was found. What does that mean?
    Every release it tried, starting from `latest`, declares peer dependencies (typically on `@angular/core`) that conflict with the versions installed in the workspace. The CLI lists the conflicts. The fix is to add a release line that supports your Angular major, for example `ng add some-lib@18`, or to update Angular first.
  • When would a library author set `"ng-add": { "save": false }`?
    When the package is only a setup tool whose `ng-add` schematic configures the project and is not needed afterwards. The CLI installs it in a temporary location, runs the schematic, then cleans up, so `package.json` never lists it.

saying these in an interview costs you the question

  • Says ng add is just an alias for npm install
  • Believes the Angular CLI itself knows how to configure every library
  • Thinks ng add always installs the latest tag even when peer dependencies conflict
  • Runs ng add on a dirty working tree and never reviews the diff
  • Uses ng add to move an installed library to a new major version