Angular v22: Signal-First Era Arrives With Breaking Defaults

Angular v22 landed on June 3, 2026 and immediately made its position clear: the Signal-first era is not optional anymore. The release ships OnPush as the default change detection strategy for all components, promotes Signal Forms and httpResource to stable, and drops Karma in favor of Vitest as the default test runner. If your app is on v21 or older, this upgrade will break things — some of them silently. Here’s what changed, what breaks, and what to do about it.

OnPush Is Now the Default — and It Breaks Quietly

The most consequential change in Angular v22 is also the least visible: ChangeDetectionStrategy.OnPush is now the default for every component without an explicit changeDetection property. Before v22, components without a changeDetection setting used Angular’s original Default strategy — re-checking on every browser event, timer, or XHR, regardless of whether inputs actually changed. That behavior is gone.

OnPush checks for changes only when an @Input reference changes, a Signal it reads updates, ChangeDetectorRef.markForCheck() is explicitly called, or an async pipe receives a new value. The catch: Angular compares by reference equality (===). If you mutate an object’s property instead of replacing the reference — this.user.name = 'new' — the component never re-renders. No error, no warning. The view just freezes.

The biggest landmines are third-party UI libraries built without OnPush assumptions. If your component kit hasn’t issued an Angular 22 compatibility update, expect broken views on upgrade. The short-term escape hatch is an explicit opt-out per component:

// Temporarily preserve pre-v22 behavior during migration
@Component({
  changeDetection: ChangeDetectionStrategy.Default,
  // ...
})
export class LegacyComponent { }

The long-term fix is Signals. Signal mutations tell Angular exactly what changed, eliminating the reference-equality problem entirely. This is Angular forcing the upgrade path they’ve been recommending for two years — with the OnPush-as-default RFC completing after extensive community discussion.

Signal Forms Are Stable — and Worth the Migration Pain

Signal Forms graduate from experimental (introduced in v21) to stable in Angular v22. The API represents form state — values, validation, dirty state — as Signals rather than FormControl observables. The practical difference is fine-grained updates: changing one field in a 100-field form triggers only that field’s re-check, not the entire form tree. Real production data shows a 40% reduction in re-renders on form-heavy pages after migrating to Signal Forms plus Zoneless mode.

However, there’s no automatic schematic for migrating from Reactive Forms. The migration is manual, and the official Angular Signal Forms migration guide provides an interoperability path — existing FormControl instances can coexist inside a Signal Form during transition. Teams with large form-heavy codebases should prioritize this migration. The performance delta is measurable with Angular DevTools, and the absence of subscription cleanup removes an entire class of memory leak bugs.

Related: TypeScript 7: Go Compiler, Breaking Changes, Migration Guide

Vitest Replaces Karma — the Migration Schematic Is Not Enough

Karma is removed as the default test runner. Vitest is now the default for new Angular projects, and existing projects need to migrate. In large workspaces, Vitest runs tests five to ten times faster than Karma, with native ES Module support and hot module replacement during test runs. The payoff is real. Getting there takes work.

The migration involves four steps, and the Angular Architects migration guide covers the gotchas the official docs skip:

# Step 1: Update Angular
ng update @angular/core@22 @angular/cli@22

# Step 2: Remove Karma
npm uninstall karma karma-chrome-launcher karma-coverage-istanbul-reporter karma-jasmine jasmine-core

# Step 3: Install Vitest
npm install --save-dev vitest@^4.0.0 jsdom @vitest/coverage-istanbul

# Step 4: Run migration schematic — review output manually
npx ng g @schematics/angular:refactor-jasmine-vitest

Step 4 gets you most of the way there, but the schematic is explicitly marked experimental. It doesn’t replace deprecated waitForAsync calls or update all toBeTruthy matchers — plan for manual cleanup. Additionally, replace --code-coverage with --coverage in your test scripts, and note that ng-reflect-* attributes are no longer emitted. Any tests relying on those attributes will fail without any helpful error message pointing to the cause.

httpResource Stable: The Subscribe Pattern Is Now Legacy Code

httpResource and rxResource are now stable, providing signal-native data fetching that replaces the HttpClient subscribe-and-teardown pattern for component-level HTTP calls. The difference in boilerplate is significant:

// Before v22: subscribe with manual teardown
export class UserComponent implements OnInit, OnDestroy {
  user: User | null = null;
  private destroy$ = new Subject<void>();
  ngOnInit() {
    this.http.get<User>('/api/user')
      .pipe(takeUntil(this.destroy$))
      .subscribe(u => this.user = u);
  }
  ngOnDestroy() { this.destroy$.next(); }
}

// v22: httpResource — no subscriptions, no teardown
export class UserComponent {
  user = httpResource<User>('/api/user');
  // user.value() — data  |  user.isLoading() — loading  |  user.error() — errors
}

RxJS is not deprecated. Complex async orchestration — retries, races, event streams — still belongs in RxJS. httpResource targets the simple case that represents the majority of component-level data fetching. It makes the memory-safe pattern the default pattern, which matters in large enterprise Angular apps where subscription leaks are a recurring production issue. See the official Angular testing migration guide for parallel guidance on the Vitest side.

Related: React 19.2: Fix Tab State Loss and Stale Closures Now

Angular v22 Migration: What to Do Right Now

Angular v22 is a consolidation release. The experiments are over — signals, Vitest, and Signal Forms have all graduated. The question now is how fast your team can absorb the migration cost. Start here before upgrading production:

• Run ng update @angular/core@22 @angular/cli@22 in a feature branch — do not merge until you’ve audited OnPush breakage across your component tree
• Grep for components without an explicit changeDetection property and add ChangeDetectionStrategy.Default as a temporary marker while migrating each one
• Audit third-party UI libraries for Angular 22 compatibility before upgrading production — component kits built without OnPush assumptions will break visibly
• Run the Vitest migration schematic, then manually review the output — budget at least one sprint for a medium-sized test suite
• For all new components and new forms, use Signal Forms and httpResource from day one — there’s no reason to start with patterns that are now legacy