Standardizing Angular Environments Across a Distributed Team

Last updated: July 2026. Reflects Angular 22 (released June 3, 2026) and Node 24 (Active LTS)

Installing Angular CLI is one command. It takes about ten seconds. And yet it’s one of the most common sources of wasted engineering time on distributed teams.

Picture this: a new hire on your remote team runs ng build locally, and everything passes. They push their PR. CI fails immediately because your pipeline runs Node 20 and they installed Angular CLI on Node 18. Two engineers spend an hour in a Slack thread diagnosing the mismatch. A feature that should have shipped today ships tomorrow.

This article covers how to install Angular CLI correctly, how to check your Angular version, and how to standardize environment setup so every engineer on your distributed team builds against the same stack. No hand waving. Just the steps, the version pinning strategies, and the team workflows that eliminate “works on my machine” as a category of bug.

In this article:

• Why Angular CLI Setup Breaks Down on Remote Teams
• Installing Angular CLI the Right Way
• How to Check Your Angular Version
• Standardizing Setup Across a Distributed Team
• A Quick Setup Checklist for New Engineers
• Common Mistakes That Cause “Works on My Machine” Bugs
• Frequently Asked Questions

Why Angular CLI Setup Breaks Down on Remote Teams

The Angular CLI works fine in isolation. Problems start when five engineers on three operating systems each install it their own way:

Global vs. local install conflicts

One engineer runs npm install -g @angular/cli and gets version 19. Another ran the same command six months ago and still has version 17 globally. Both run ng serve on the same repo. One gets deprecation warnings. The other gets build errors. Neither knows what the other is seeing.

Node.js version mismatches

Angular’s documentation lists v20.19.0 as the historical minimum, but Angular 22 requires v22.22.0 or v24.13.1 at minimum; and Node 20 is EOL as of April 2026. Always pin to a supported LTS version, not the floor.

If one contributor is on Node 18 and another on Node 22, you’ll see different dependency resolution, different build output, and sometimes silent failures that only surface in production.

OS specific path and permission issues

On macOS and Linux, global npm installs can fail with EACCES permission errors if Node was installed through the system package manager. On Windows, PATH resolution for the ng command behaves differently depending on whether Node was installed via the .msi installer or a version manager. These differences stay invisible until someone’s build breaks.

CI/CD environment drift

Your CI pipeline pins Node 20.19.0 and installs dependencies with npm ci. Your developer runs Node 20.14.0 locally with npm install. The lockfile resolves differently. The build passes locally and fails in CI. A senior engineer spends 45 minutes tracing the issue back to a minor Node version difference. That’s real sprint velocity lost to environment drift, not to a hard technical problem.

Installing Angular CLI the Right Way

Before you run an Angular CLI install, verify your Node.js and npm versions:

node -v

npm -v

You need Node.js v22.22.0 or newer for Angular 22. Angular’s stated floor is v20.19.0, but Angular 22 dropped Node 20 support entirely; and Node 20 reached EOL on April 30, 2026, meaning no further security patches. 

Pin to Node 24 (Active LTS, EOL April 2028) for new projects, or Node 22 (Maintenance LTS, EOL April 2027) if your existing stack requires it.

Angular 22 also requires TypeScript 6. Check your version with tsc –version and update with npm install –save-dev typescript@6 if you’re below that.

The standard install. To install Angular CLI globally, run:

npm install -g @angular/cli

If your team uses an alternative package manager, Angular’s official tooling supports all four. The equivalent commands:

# pnpm

pnpm add -g @angular/cli

# yarn

yarn global add @angular/cli

# bun

bun add -g @angular/cli

For team-pinned local installs, substitute pnpm add –save-dev, yarn add –dev, or bun add –dev respectively. The npx equivalent for pnpm is pnpm dlx.

This makes the ng command available system-wide. For solo projects or quick prototypes, this is fine.

The team-safe approach. For teams, skip the global install. Use npx to run the CLI at the version your project expects:

npx @angular/cli@22 new my-project

Inside an existing project, add the CLI as a dev dependency:

npm install –save-dev @angular/cli@22

Then run commands through npx:

npx ng serve

This guarantees every contributor uses the same CLI version, regardless of what’s installed globally on their machine.

Pin your Node version. Add a .nvmrc file to your project root:

24.18.0

Or use Volta to pin both Node and npm:

volta pin node@24

volta pin npm@10

When a new engineer clones the repo, their Node version switches automatically. No guesswork, no Slack thread asking what version everyone’s on.

How to Check Your Angular Version (and Why It Matters)

Knowing how to check Angular version should be muscle memory for every engineer on your team, not something you Google mid-incident.

Using the CLI. Run either command:

ng version

ng –version

Both return your Angular CLI version, the Angular framework version, Node.js version, npm version, and OS. This is the fastest way to check the Angular version during troubleshooting.

Checking package.json. The CLI output tells you what’s installed globally. To check the project’s actual Angular version, open package.json and look at @angular/core:

“dependencies”: {

“@angular/core”: “~22.0.0”

}

If a teammate’s ng version shows Angular 20 but the project specifies Angular 22, you’ve found your bug before it reaches code review.

Make it an onboarding step. Add “run ng version and paste the output” to your onboarding checklist. It takes ten seconds and catches version mismatches before a PR ever fails.

Standardizing Setup Across a Distributed Team

A single engineer can eyeball a version mismatch in five minutes, but a team of eight engineers across four time zones can’t. If your Berlin and Manila developers never overlap in real time, a silent version drift between their machines can sit undetected for a full sprint, surfacing only when their branches merge, and CI throws an error neither of them can reproduce locally. 

That’s the actual cost of treating setup as a personal preference instead of a team-wide standard. What you can do about it:

1. Lock CLI and Angular versions in package.json. Never rely on global installs for production projects. Pin @angular/cli as a devDependency and use npm ci, not npm install, in CI. This guarantees reproducible installs tied to package-lock.json.
2. Enforce Node versions across contributors. Three options, ranked by enforcement strength:

• engines in package.json: the simplest starting point. Add this to your project’s package.json and npm will warn (and optionally fail) when a contributor’s Node version falls outside the declared range:

“engines”: {

  “node”: “>=22.22.0”,

  “npm”: “>=10”

}

Enforcement is soft by default — npm warns but doesn’t block. Add engine-strict=true to a project-level .npmrc to make it a hard error. Zero friction to set up; limited enforcement on its own.”

Then re-number the existing options:

• engines in package.json: zero friction, soft enforcement
• .nvmrc: low friction, medium enforcement
• Volta: higher enforcement
• Docker dev containers: highest enforcement, highest setup cost

• .nvmrc: works if everyone uses nvm. Low friction, medium enforcement.
• Volta: pins Node and npm per project, enforced automatically on cd. Higher enforcement.
• Docker dev containers: full environment isolation, same OS and toolchain for every contributor. Highest enforcement, highest setup cost.

3. Document everything in the README. If your setup process lives in someone’s head or a Slack thread from last year, it isn’t a process. Your README should include required Node and npm versions, exact install commands, expected ng version output, and how to confirm local builds match CI.

Angular 22 ships the Angular CLI MCP server (ng mcp) as a stable feature. Running it exposes your Angular project’s context to AI coding tools (Claude, GitHub Copilot, Cursor), so AI-generated code suggestions are aware of your project’s Angular version, component structure, and CLI capabilities. 

For distributed teams, this matters most during onboarding: a new remote engineer can use an AI tool that already understands your specific project’s setup rather than generating generic Angular snippets that may not match your version or conventions. Enable it with ng mcp in your project root.

4. Add CI checks that fail fast. Here’s a GitHub Actions step that reads the Node version straight from your project’s .nvmrc:

# .github/workflows/ci.yml

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

   – uses: actions/checkout@v5

– uses: actions/setup-node@v5

  with:

    node-version-file: ‘.nvmrc’

      – run: npm ci

      – run: npx ng version

      – run: npx ng build

This ties CI to the same source of truth every contributor already uses locally, so there’s no separate version number to update in two places when you upgrade Node. If someone bumps .nvmrc without testing, CI installs that version, runs npm ci against the lockfile, and fails on the build step rather than passing silently with a mismatched dependency tree.

Catch mismatches in the pipeline, not in code review:

Approach	Consistency	Onboarding Speed	CI Parity	Maintenance Overhead
Global install	Low, each machine differs	Fast but error-prone	Poor, global does not match CI	Low effort, high hidden cost
Local/project install	High, pinned in package.json	Moderate, requires docs	Good, matches CI versions	Moderate, update lockfiles
Dev container	Very high, identical environments	Slower initial setup, fast after	Excellent, mirrors CI exactly	Higher, maintain container config

Read more: On-Site vs Remote vs Distributed Engineering Teams: How to Choose?

A Quick Setup Checklist for New Engineers

Save this and drop it into your onboarding doc:

1. Install Node.js v24 (Active LTS) using nvm or Volta, not the system installer — Node 20 is EOL and no longer receives security patches
2. Verify with node -v and npm -v
3. Clone the project repo
4. Run npm ci to install exact locked dependencies
5. Run npx ng version and compare output to the README’s expected versions
6. Run npx ng serve and confirm the app loads at localhost:4200
7. Run npx ng build and confirm it completes without errors
8. Push a trivial change and confirm CI passes

If any step fails, stop and resolve it before writing code. An hour spent debugging environment issues on day two is an hour not spent shipping features.

Common Mistakes That Cause “Works on My Machine” Bugs

• Mixing global and local CLI versions. Global ng is v20; the project expects v22. Running ng generate component produces a scaffold with outdated syntax. Fix: use npx ng, or remove the global install entirely.
• Ignoring package-lock.json. Running npm install instead of npm ci lets npm resolve slightly different dependency versions than the lockfile specifies. The build works locally and fails in CI. Fix: use npm ci in CI and treat lockfile changes as meaningful diffs.
• Skipping Node version pinning. “Any recent Node should work” holds true until it doesn’t. A minor Node version difference can change how core modules behave, breaking Angular’s build tooling in confusing ways. Fix: pin with .nvmrc or Volta.
• Assuming every OS behaves the same. macOS is case-insensitive by default; Linux and most CI runners are case-sensitive. An import that resolves fine on Mac will fail on Linux. Fix: enforce consistent file casing and add a CI lint step that catches it.
• Following outdated documentation. Angular’s docs moved from angular.io to angular.dev. Older tutorials reference deprecated flags or older Node versions. Fix: always confirm you’re reading docs for your target Angular version.
• Skipping ng update when upgrading. Running npm install @angular/cli@22 without running ng update @angular/core @angular/cli afterward leaves behind migration schematics that update deprecated APIs, configuration files, and build settings automatically.
  
  The manual install gets you the new version; ng update applies the automated migration that the Angular team wrote specifically so you don’t have to find every breaking change yourself.

Frequently Asked Questions

How do I install Angular CLI? 

Run npm install -g @angular/cli for a global install, or npm install –save-dev @angular/cli inside a project for a team-safe local install. Confirm Node.js v20.19.0 or newer is installed first.

How do I check what version of Angular I’m running? 

Run ng version or ng –version in your terminal. This shows your Angular CLI version, framework version, Node.js version, and OS in a single output.

What is the difference between Angular CLI and the Angular framework? 

The CLI (@angular/cli) is the tooling that scaffolds, builds, and serves your app. The framework (@angular/core and related packages) is the actual library your app runs on. Installing the CLI does not install the framework; that happens per project when you run ng new or npm install.

Why does ng version show a different version than my project uses? 

This usually means you have a global CLI install that doesn’t match the version pinned in your project’s package.json. Run commands through npx ng instead of the global ng to force the project’s local version.

Do I need to install Angular CLI globally? 

No. Global installs are convenient for quickly scaffolding new projects, but team projects are safer with a local, project-pinned install run through npx. This avoids version conflicts between projects that expect different Angular releases.

Hire Angular Developers Who Ship From Day One

Standardizing your Angular setup solves half the onboarding problem. The other half is hiring engineers who already work this way, and that’s harder to solve with a README.

A resume tells you a candidate has “5 years of Angular experience”, but it doesn’t tell you whether they know to pin a Node version before touching ng new, or whether they’ve spent a sprint chasing a bug that turned out to be a lockfile mismatch. Arc’s vetting process is built to catch that gap.

Arc pre-vets Angular developers for technical depth and English fluency before you see a profile. HireAI matches your requirements against a pool of vetted candidates and returns a shortlist in minutes, not weeks.

Hire Angular developers with Arc →