Angular: From Zero to Expert

NgRx 22: three changes that make SignalStore easier to use

Amos Isaila — Mon, 26 Oct 2026 05:38:27 GMT

NgRx 22 makes a few common SignalStore tasks easier. You can keep old data on screen while new data loads, work with values such as Movie | null, and reuse the type of one store feature inside another.

Angular sanitises by default. Here is where that sentence runs out.

Amos Isaila — Sun, 04 Oct 2026 20:50:49 GMT

This is a guided tour of representative vulnerability classes, not a claim to contain every vulnerability Angular could ever have. For each one I want to be specific about three things: what the mechanism actually is, what has to be true in your app for it to bite you, and what you do about it. Every version number and API name below was checked against the installed type definitions of @angular/core@22.1.4, @angular/common@22.1.4, @angular/platform-browser@22.1.4 and @angular/build@22.1.6, or against the primary advisory. The official advisory list was rechecked on 16 September 2026. Where I’m reading someone else’s incident report rather than code, I’ll say so.

The Hour That Doesn’t Exist

Amos Isaila — Wed, 30 Sep 2026 03:28:32 GMT

You have a bug. The cron expression was fine, the container was healthy, the logs were clean. There was simply no 2:30 that night. The clocks went from 01:59:59 straight to 03:00:00, and the thirty minutes past two never happened.

Angular 22.2: What's new

Amos Isaila — Thu, 24 Sep 2026 21:30:44 GMT

🏗️ Framework

Templates & Compiler

a) Templates can access private component members — PR

Angular templates can now read and call TypeScript private members declared directly on their component.

import {
  ChangeDetectionStrategy,
  Component,
} from '@angular/core';

@Component({
  selector: 'app-status',
  template: `{{ _status }}`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class StatusComponent {
  private readonly _status = 'Ready';
}

Previously, the template type checker reported an error for _status. Angular 22.2 allows this direct access, which is helpful for members that exist only to support the component template.

This applies to TypeScript private members of the component itself. It does not make a nested object’s private properties accessible, and it does not apply to JavaScript #private fields.

b) Catch misspelled output bindings — PR

The new strictUnclaimedEventNames option catches camelCase output names that do not belong to the component and are not native DOM events:

Enable it explicitly in tsconfig.json:

{
  "angularCompilerOptions": {
    "strictUnclaimedEventNames": true
  }
}

It is disabled by default and intentionally ignores lowercase or dash-separated custom events to reduce false positives.

Core & Reactivity

a) Catch errors from dynamically created views — PR

Angular can now catch rendering and lifecycle errors from a component created with ViewContainerRef.

private readonly _container = inject(ViewContainerRef);

showReport(): void {
  this._container.createComponent(ReportComponent, {
    onError: (error: Error): void => console.error('Report failed', error),
  });
}

Previously, these errors reached the global ErrorHandler. Now a dynamically created view can handle its own failure. The new error-boundary APIs are available as Developer Preview.

b) Read an element’s `Injector` from a query — PR

viewChild() and contentChild() can now return the injector attached to the matched element.

@Component({
  imports: [ThirdPartyWidgetComponent],
  template: ``,
})
export class WidgetHostComponent {
  readonly widgetInjector = viewChild('widget', { read: Injector });
}

This lets wrapper components access providers exactly as the child element sees them. It removes the need to create a helper directive just to capture that injector. This is a public API.

Forms

a) Permanently hidden fields in Signal Forms — PR

Signal Forms can now mark a field as permanently hidden. Call hidden() with only the field path, without a condition or configuration object.

import { signal } from '@angular/core';
import { form, hidden } from '@angular/forms/signals';

const profile = signal({
  name: '',
  internalId: '',
});

const profileForm = form(profile, (path) => {
  hidden(path.internalId);
});

internalId stays hidden even when its value changes. Angular also excludes the field from active validation while it is hidden.

This is useful for fields that belong to the model but should never appear in the current form, such as internal identifiers or values managed by the application.

b) Signal Forms explain their behavior to AI agents — PR

An experimental WebMCP Signal Form can be filled and submitted by a browser AI agent. Angular now tells the agent two things about that form automatically:

{
  readOnlyHint: false,
  untrustedContentHint: false,
}

readOnlyHint: false: submitting the form changes the page or application state.
untrustedContentHint: false: Angular currently considers the form response trusted.

There is nothing new to configure. This is extra safety information that Angular adds behind the scenes. WebMCP support is still experimental.

Router

a) Throw `RedirectCommand` from guards and resolvers — PR

Guards and resolvers can now throw a RedirectCommand to stop the current navigation and redirect immediately.

import { inject } from '@angular/core';
import {
  CanActivateFn,
  RedirectCommand,
  Router,
} from '@angular/router';

export const authGuard: CanActivateFn = () => {
  const router = inject(Router);

  throw new RedirectCommand(router.parseUrl('/login'));
};

Previously, a nested helper had to return the redirect through every function in the call chain. Now it can throw the command directly, keeping the guard or resolver return type focused on its normal result.

b) Public `containsTree` API for URL matching — PR

The Router now exports containsTree, allowing applications and libraries to compare two UrlTree objects directly.

import { inject, Injectable } from '@angular/core';
import { containsTree, Router } from '@angular/router';

@Injectable({ providedIn: 'root' })
export class UrlMatcher {
  private readonly _router = inject(Router);

  isInside(url: string, parent: string): boolean {
    return containsTree(
      this._router.parseUrl(url),
      this._router.parseUrl(parent),
    );
  }
}

Calling isInside('/products/42/details', '/products') returns true.

By default, paths and query parameters use subset matching. You can pass options such as { paths: 'exact' } when you need stricter behavior.

This is useful for custom navigation components, breadcrumbs and route-aware libraries that need URL matching without depending on private Router internals.

c) ⚠️ Automatic route-injector cleanup is now stable — PR

Detached routes can leave their injectors—and the services created inside them—alive. Enabling this feature lets Angular destroy an injector when its route is no longer active or saved for reuse.

The feature is now stable. Only its name changes:

// Before ❌
provideRouter(routes, withExperimentalAutoCleanupInjectors());

// Angular 22.2 ✅
provideRouter(routes, withAutoCleanupInjectors());

The old function still works, but it is deprecated. Custom RouteReuseStrategy implementations also get stable hooks for telling Angular which saved routes must keep their injectors.

d) Load route data with Signals and Resources — PR

Router Resources are a reactive alternative to resolvers. They can load data for a route, expose loading and error states, and reload without navigating again.

First, enable them:

provideRouter(routes, withRouterResources());

Then define the resource on the route:

{
  path: 'products/:id',
  component: ProductPageComponent,
  resources: (route) => {
    const products = inject(ProductService);

    return {
      product: resource({
        params: () => String(route.params()['id']),
        loader: ({ params: id }) => products.get(id),
      }),
    };
  },
}

Resources from parent and child routes load in parallel, avoiding the sequential waits that nested resolvers can create. They are public in Angular 22.2, but remain in Developer Preview.

Developer Tooling

a) Explicit workspace roots for Angular MCP — PR

The Angular MCP command now accepts --root. It defines which directories the MCP server may access and use for workspace discovery.

ng mcp --root ./frontend --root ./shared

You can repeat the option for multi-root workspaces. This also lets an MCP host start Angular outside the project root while still passing the allowed directories explicitly.

b) Test directives without creating a host component — PR

Previously, testing a directive usually required creating a temporary host component. The new public TestBed.createDirective() API creates the directive and its HTML element directly.

import { Directive } from '@angular/core';
import { TestBed } from '@angular/core/testing';

@Directive({
  selector: '[appHighlight]',
  host: { class: 'highlighted' },
})
class HighlightDirective {}

it('highlights its host element', (): void => {
  const fixture = TestBed.createDirective(HighlightDirective, {
    tagName: 'button',
  });

  fixture.detectChanges();

  expect(fixture.nativeElement.classList.contains('highlighted')).toBe(true);
});

The fixture gives us the directive instance, its real host element and change detection. Tests become shorter because the artificial host component disappears.

c) WebMCP tools can declare safety annotations — PR

WebMCP lets a web application expose actions to browser AI agents. A tool can now describe its safety characteristics through two annotations:

import { provideExperimentalWebMcpTools } from '@angular/core';

export const webMcpProviders = provideExperimentalWebMcpTools([
  {
    name: 'readAccountStatus',
    description: 'Reads the current account status.',
    inputSchema: { type: 'object', properties: {} },
    annotations: {
      readOnlyHint: true,
      untrustedContentHint: false,
    },
    execute: () => ({
      content: [{ type: 'text', text: 'The account is active.' }],
    }),
  },
]);

Here, readOnlyHint: true tells the agent that calling the tool changes nothing. untrustedContentHint: false says its response is controlled by the application rather than an external source.

The names are a bit technical, but the idea is simple: the AI agent gets more context before deciding whether and how to use a tool. These are hints, not security enforcement, and WebMCP remains experimental.

Language Tooling

a) Editor support for `@boundary` blocks — PR

The Angular Language Service now understands the new error-boundary syntax:

@boundary {
  
} @error (let error) {
  Payment failed: {{ error.message }}
}

Editors can now highlight, fold and navigate these blocks correctly, as well as provide hover information. This does not add another application API; it adds editor support for the Developer Preview error-boundary feature.

🛠️ CLI & Build Tooling

Build System

a) Angular Linker moves from Babel to OXC — PR

The Angular Linker in the build pipeline now uses oxc-parser and magic-string instead of @babel/core and the Angular Linker Babel plugin.

OXC provides the syntax tree and exact token positions, while magic-string updates partial Angular declarations directly in the original source. This removes Babel from this part of the build pipeline and reduces the amount of work needed to link partially compiled libraries.

b) ⚠️ Separate browser and server build statistics — PR

Angular can now produce separate statistics for browser, server and initial bundles. This makes the output easier to load into bundle analyzers, especially for SSR applications where one combined file contains too much unrelated data.

Generate the files with the existing option:

ng build --stats-json

The generated output has changed:

// Before ❌
dist/stats.json

// After ✅
dist/browser-stats.json
dist/browser-initial-stats.json
dist/server-stats.json          # SSR only
dist/server-initial-stats.json  # SSR only

The initial files contain only the initial page bundles, while the full files include every corresponding browser or server output.

This is a breaking change for scripts and CI jobs that expect stats.json. Update those paths to the appropriate new file. For example, use browser-initial-stats.json when you only want to inspect the initial browser payload.

⚠️ Breaking Changes & Deprecations

Angular 22.2 does not declare any formal breaking changes. However, it includes one build-output change that can break existing pipelines and two deprecations.

Build statistics file names — PR #33870
Enabling statsJson no longer creates stats.json. Browser builds now generate browser-stats.json and browser-initial-stats.json; SSR builds also generate their server equivalents. Update scripts and analyzers that expect the old filename.
Deprecated experimental Router cleanup name — PR #70443
Replace withExperimentalAutoCleanupInjectors() with the stable withAutoCleanupInjectors(). The deprecated function still delegates to the stable implementation, so this migration does not need to happen all at once.
Deprecated splitting option in the unit-test builder — PR #34031
Remove splitting from the options of @angular/build:unit-test. It is no longer necessary with Vitest 5 and has no replacement.

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don’t forget to follow me and stay in the loop: 📱

🔗 LinkedIn
📝 Medium
🎥 YouTube
🐦 X

Thanks for being part of this Angular adventure! 👋😁

Angular Content Projection Has a Real Design Problem

Amos Isaila — Sun, 30 Aug 2026 22:26:28 GMT

Look how simple is content projection in Angular:


  Signals and forms
  The body of the card.

The card decides where each node goes:

This works well until the projected content becomes conditional, deferred, repeated, or dynamically created. Then we run into fallback content that never appears, ngProjectAs workarounds, awkward TemplateRef APIs, and projectableNodes arrays that require knowledge of a component’s internal slot order.

The Angular team is now collecting these cases in Canonical: Content Projection — issue #64504. The important point is that Angular does not see them as separate bugs. They are consequences of the same underlying model.

What signals actually did to Angular lifecycle hooks

Amos Isaila — Tue, 25 Aug 2026 22:44:07 GMT

Two of the eight hooks aren’t replaced by signals at all.

Let’s start with what’s actually in the framework. I checked @angular/core@22.1.2 and all eight lifecycle interfaces are still exported. Not one of them is marked deprecated. They all live in a single file, packages/core/src/change_detection/lifecycle_hooks.ts, pinned here to the v22.1.2 tag:

OnChanges
OnInit
DoCheck
OnDestroy
AfterContentInit
AfterContentChecked
AfterViewInit
AfterViewChecked

I built a small app where each hook’s old and new version sit side by side, and I’ll point at it as we go. I also managed to write a genuinely bad bug in that app, which turned out to be the best part of the exercise.

Angular 22.1: What's new

Amos Isaila — Thu, 30 Jul 2026 00:22:21 GMT

🏗️ Framework

Core & Reactivity

a) Custom `set` option for `linkedSignal` - PR

linkedSignal now accepts a custom set callback. It lets you redirect writes to the original source signal instead of replacing the linked signal’s internal value.

Consider a temperature value stored in Celsius but displayed and edited in Fahrenheit:

import { linkedSignal, signal } from '@angular/core';

const tempC = signal(0);

const tempF = linkedSignal(
  () => (tempC() * 9) / 5 + 32,
  {
    set: (valueF: number) => {
      tempC.set(((valueF - 32) * 5) / 9);
    },
  },
);

console.log(tempF()); // 32

tempF.set(212);

console.log(tempC()); // 100
console.log(tempF()); // 212

Calling tempF.set(212) redirects the update to tempC. Since tempF depends on tempC, it recalculates automatically and the reactive graph remains consistent.

The callback also receives a second argument called rawSet. You can use it when you need to update the linked signal directly and preserve its original write behavior.

const value = linkedSignal(source, {
  set: (
    newValue: number,
    rawSet: (value: number) => void,
  ): void => {
    if (shouldUpdateSource(newValue)) {
      source.set(newValue);
    } else {
      rawSet(newValue);
    }
  },
});

This is useful for editable derived values, form-like state and properties extracted from larger parent signals.

Thanks for reading Angular: From Zero to Expert! This post is public so feel free to share it.

a) CSS Variable Namespacing - PR

Running multiple Angular applications on the same page can cause CSS variables to leak between them. One application may set --primary-color, and another embedded application can accidentally inherit it.

Angular 22.1 introduces CSS variable namespacing for component styles:

import {
  APP_ID,
  ApplicationConfig,
} from '@angular/core';
import { provideCssVarNamespacing } from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {
  providers: [
    {
      provide: APP_ID,
      useValue: 'storefront',
    },
    provideCssVarNamespacing('storefront_'),
  ],
};

You can continue writing regular CSS variables:

:host {
  --primary-color: blue;
  color: var(--primary-color);
}

Angular transforms them using the configured namespace:

:host {
  --my-app_primary-color: blue;
  color: var(--my-app_primary-color);
}

Only styles declared through styles or styleUrls in Angular components are transformed. Global stylesheets remain unchanged.

Variables beginning with --global-- are deliberately excluded:

:host {
  --global--shared-spacing: 16px;
}

Template bindings such as [style.--highlight] are also namespaced. Code that accesses variables programmatically should use CssVarNamespacer, especially in libraries where the consuming application may enable namespacing.

b) Smaller generated output for foreign components — PR

The compiler no longer emits a redundant tag name when a foreign component is the root of an @if, @for or @switch block.

This is a small internal performance improvement that reduces generated output without requiring application changes.

HTTP

a) More control over the HTTP transfer cache - PR

Angular’s HTTP transfer cache stores server responses during SSR so the browser doesn’t immediately request the same data again during hydration.

Angular 22.1 adds two options:

includeRequestsWithCredentials
includeNonCacheableRequests

import { ApplicationConfig } from '@angular/core';
import {
  provideClientHydration,
  withHttpTransferCacheOptions,
} from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(
      withHttpTransferCacheOptions({
        includeRequestsWithCredentials: true,
        includeNonCacheableRequests: true,
      }),
    ),
  ],
};

includeRequestsWithCredentials allows requests using withCredentials or Fetch credential modes to enter the transfer cache.

includeNonCacheableRequests permits requests and responses normally excluded by Cache-Control, Set-Cookie or Fetch cache options.

Both options default to false. Enable them only when the response is safe to serialize into the server-rendered page—particularly when SSR output might be cached or shared.

b) ⚠️ JSONP support is deprecated — PR

Angular has deprecated JSONP because it executes arbitrary scripts in the global context. This can bypass modern Content Security Policies and introduce cross-site scripting risks.

The deprecation covers:

HttpClient.jsonp()
HttpClientJsonpModule
JsonpClientBackend
JsonpInterceptor
jsonpInterceptorFn
jsonpCallbackContext
withJsonpSupport()

// Before ❌
this._http.jsonp(
  ‘https://api.example.com/data’,
  ‘callback’,
);

// After ✅
this._http.get(
  ‘https://api.example.com/data’,
);

Remove withJsonpSupport() from your HTTP providers as part of the migration.

If an external API only supports JSONP, use a backend proxy or move to an endpoint supporting CORS. Angular intends to remove JSONP in a future version.

Router

a) Nullable inputs for `RouterLinkActive` - PR

RouterLinkActive now accepts null and undefined for both routerLinkActive and routerLinkActiveOptions.

Reusable link components previously needed duplicated @if branches when active styling was optional. The directive can now remain in one template:

The behavior depends on the input:

routerLinkActive: null | undefined applies no active classes.
routerLinkActiveOptions: undefined uses the default subset match.
routerLinkActiveOptions: null disables active matching.

That means fewer conditional branches and fewer unnecessary comment nodes in reusable navigation components.

Language Tooling

a) Compile non-exported classes if standalone - PR

The Angular Language Service now compiles standalone classes that aren’t exported from their file. Previously, if you had a component that wasn’t exported (common in single-file route components or test files), the language service would skip it — meaning no autocompletion, no type-checking, no diagnostics in your template.

b) Typecheck templates requiring inline typecheck blocks - PR

Part of the same PR — the language service can now type-check templates that would require inline type-check blocks. Previously, certain template patterns that the compiler couldn’t handle with external type-check files were simply skipped by the language service. Now they get full diagnostics.

Developer Tooling

a) Deep linking from Chrome’s Performance panel - PR

Angular component events recorded in Chrome’s Performance panel can now link directly to the corresponding component inside Angular DevTools.

The recorded event contains a URL using this format:

angular-devtools://component/{instanceId}

Selecting it opens that specific component instance in Angular DevTools, making it easier to move from a performance problem to the component responsible for it.

The integration currently depends on Chrome’s DevTools extensibility support and may require enabling:

chrome://flags/#enable-devtools-deep-link-via-extensibility-api

🛠️ CLI & Build Tooling

a) Angular MCP server enabled by default in new workspaces - PR

The ai-config schematic now includes Angular MCP server configuration.

New workspaces created with AI configuration can connect supported AI tools to Angular’s development capabilities with less manual setup.

b) ⚠️ Deprecation of `stringToFileBuffer` and `fileBufferToString` in `@angular-devkit/core`

stringToFileBuffer and fileBufferToString from @angular-devkit/core are now deprecated. The replacement is the standard Web APIs: TextEncoder and TextDecoder.

// Before ❌
import { stringToFileBuffer, fileBufferToString } from '@angular-devkit/core';

const buffer = stringToFileBuffer('hello');
const str = fileBufferToString(buffer);

// After ✅
const encoder = new TextEncoder();
const decoder = new TextDecoder();

const buffer = encoder.encode('hello');
const str = decoder.decode(buffer);

c) Share Build Cache Across Git Worktrees - PR

Angular now shares its persistent build cache across Git worktrees belonging to the same repository.

Instead of creating a separate .angular/cache directory in every worktree, Angular resolves the cache from the main repository:

main-repository/
├── .angular/cache/
├── worktree-feature-a/
└── worktree-feature-b/

Regular repositories and Git submodules retain their existing behavior. If worktree detection fails, Angular safely falls back to the workspace-relative cache.

This reduces duplicated cache files and avoids rebuilding the same artifacts across parallel branches.

d) Chunk optimization for server builds — PR

Angular can now optimize browser chunks even when an application uses SSR or has a server entry point.

For those unfamiliar with OXC: it’s a collection of high-performance JavaScript and TypeScript tools written in Rust. Angular uses its fast parser to reduce build times, with no extra configuration required.

e) Faster production optimizations with OXC — PR

Angular moved several internal production optimizations from Babel to the faster OXC parser.

f) Much faster localized builds — PR

Angular’s localization worker now uses OXC and magic-string instead of Babel.

📦 Migrations & Schematics

a) `@Injectable` to `@Service` migration schematic - PR

Angular now ships an automated migration schematic that converts eligible @Injectable classes to the new @Service decorator. This is part of the broader push toward more semantic decorators — @Service communicates intent more clearly than @Injectable, which was always a bit of a misnomer (it describes how the class participates in DI, not what it is).

Run it with:

ng generate @angular/core:service

Or target a specific directory:

ng generate @angular/core:service --path src/app/features

What it does:

// Before ❌
import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class UserService {}

// After ✅
import { Service } from '@angular/core';

@Service()
export class UserService {}

The schematic handles the import swap automatically — replacing Injectable with Service in the import statement and updating the decorator call.

Limitations — the schematic will skip classes that:

Use constructor-based dependency injection (since @Service is designed for the inject() pattern)
Pass any options into @Injectable aside from providedIn
Pass anything aside from 'root' into providedIn

This is conservative by design. The schematic won’t touch classes using useFactory, useClass, useValue, or useExisting providers, nor will it touch services scoped to specific modules or components. Those cases require manual review.

If you’re already following modern Angular patterns (using inject() instead of constructor injection, providing services at root), this migration should cover the vast majority of your services with zero manual intervention.

⚠️ Breaking Changes & Deprecations

1. JSONP Support Deprecated (`@angular/common/http`)

HttpClient.jsonp, HttpClientJsonpModule, withJsonpSupport(), and all related JSONP classes/functions are deprecated due to XSS vulnerability risks. Use standard HTTP requests with CORS instead. Intent to remove in a future Angular version.

PR: #69116

2. `stringToFileBuffer` and `fileBufferToString` Deprecated (`@angular-devkit/core`)

These utility functions are deprecated in favor of standard Web APIs (TextEncoder and TextDecoder). Internal usages have already been removed and replaced.

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don’t forget to follow me and stay in the loop: 📱

🔗 LinkedIn
📝 Medium
🎥 YouTube
🐦 X

Thanks for being part of this Angular adventure! 👋😁

Angular 22: What's new

Amos Isaila — Wed, 03 Jun 2026 22:01:12 GMT

🏗️ Framework (`angular/angular`)

Core & Reactivity

a) 🔥 Default change detection is now OnPush - PR

Components without an explicit changeDetection property now default to OnPush instead of the old Default (now renamed to Eager).

// Before Angular 22 — this was implicitly ChangeDetectionStrategy.Default
@Component({
  selector: ‘app-dashboard’,
  template: `{{ title }}`,
})
export class DashboardComponent {
  title = ‘Dashboard’;
}

// Angular 22 — same code is now implicitly OnPush
// If you need the old behavior:
@Component({
  selector: ‘app-dashboard’,
  changeDetection: ChangeDetectionStrategy.Eager, // ← new name for “Default”
  template: `{{ title }}`,
})
export class DashboardComponent {
  title = ‘Dashboard’;
}

b) Signal-native debouncing with `debounced()` - PR

Angular added a debounced() function that takes a signal and a wait time, and returns a Resource.

protected readonly searchInput = signal(’‘);

// Debounced — settles after 500ms of no typing
protected readonly debouncedSearch = debounced(() => this.searchInput(), 500);

The resource gives you .value(), .status(), .isLoading(), and .error() — loading states come for free. I wrote a full deep-dive on this: check out my Debounced Signals in Angular 22 article.

c) Nested leave animations scoped to component boundaries - PR

Leave animations are no longer limited to just the element being removed. They now propagate to nested elements within the same component boundary. If you have a parent element with :leave and child elements with their own animations, the children will now animate out properly before the parent is removed.

This is a breaking change if you relied on the old behavior where nested leave animations were silently ignored.

d) Special return statuses for resource params - PR

Resources now support special return statuses from their params function. Instead of always returning params (which triggers a load), you can now return undefined to put the resource in an idle state — meaning it won’t fetch until valid params are available.

type UserSearchParams = { query: string };

@Component({
  selector: ‘app-user-search’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    

    @switch (users.status()) {
      @case (’idle’) { Type something to search }
      @case (’loading’) { Searching... }
      @case (’resolved’) {
        @for (user of users.value(); track user.id) {
          {{ user.name }}
        }
      }
      @case (’error’) { Something went wrong }
    }
  `,
})
export class UserSearchComponent {
  protected readonly searchQuery = signal(’‘);

  protected readonly users = httpResource(() => {
    const query = this.searchQuery();

    // Return undefined → resource stays idle, no request fired
    if (query.length < 2) return undefined;

    return `/api/users?q=${encodeURIComponent(query)}`;
  });
}

The idle status is new — before this, a resource would always be in loading, resolved, or error. Now you can distinguish between “hasn’t started yet” and “currently fetching.”

Learn more about Angular resources here.

e) `TestBed.getLastFixture()` - PR

A new testing utility that returns the last created ComponentFixture. Originally introduced as TestBed.getFixture() in next.0, it was renamed to TestBed.getLastFixture() in next.4 for clarity.

it(’should render the component’, () => {
  TestBed.configureTestingModule({
    imports: [MyComponent],
  });

  const fixture = TestBed.createComponent(MyComponent);
  
  // Later in the test, if you need the fixture again:
  const sameFixture = TestBed.getLastFixture();
  expect(sameFixture).toBe(fixture);
});

f) Customizable @defer idle behavior - PR & PR

Two related changes that give you more control over @defer blocks with idle triggers:

IdleRequestOptions support — you can now customize the idle service behavior
Optional timeout for idle triggers — set a maximum wait time for idle-triggered defer blocks

// You can now configure idle behavior with timeout
@defer (on idle; timeout 5000) {
  
}

This is useful when you want a defer block to load during idle time but don’t want to wait forever if the browser stays busy.

g) Exhaustive type checking for `@switch` - PR

The @switch control flow now supports exhaustive type checking with other expressions. The compiler can verify that all possible values of a union type are handled:

type Status = ‘active’ | ‘inactive’ | ‘pending’;

@Component({
  template: `
    @switch (status()) {
      @case (’active’) { Active }
      @case (’inactive’) { Inactive }
      @case (’pending’) { Pending }
    }
  `,
})
export class StatusComponent {
  status = input.required();
}

h) ⚠️ `createNgModuleRef` removed - PR

The deprecated createNgModuleRef function has been removed. Use createNgModule instead:

// No more createNgModuleRef
const moduleRef = createNgModule(MyModule, injector);

i) ⚠️ `ChangeDetectorRef.checkNoChanges` removed - PR

ChangeDetectorRef.checkNoChanges has been removed from the public API. In tests, use fixture.detectChanges() instead.

j) ⚠️ AnimationCallbackEvent.animationComplete signature changed - PR

The animationComplete callback signature on AnimationCallbackEvent has been enhanced. If you’re using this API directly, check the new signature.

// strictly typed as VoidFunction
type AnimationCallbackEvent = {
  target: Element;
  animationComplete: VoidFunction;
};

k) Migration schematic: `ChangeDetectionStrategy.Eager` - PR

Since the default changed to OnPush, Angular provides a migration schematic that automatically adds ChangeDetectionStrategy.Eager to components that previously relied on the implicit Default strategy. Run it during ng update.

l) De-duplicate host directives - PR

If the same directive appears multiple times in a host directive chain (through inheritance or composition), it’s only applied once. Before this, duplicates could cause unexpected double-initialization or conflicting behavior.

@Directive({ host: { class: ‘tooltip’ } })
export class TooltipDirective {}

// Both BaseCard and FancyCard declare TooltipDirective as a host directive
@Component({
  selector: ‘app-base-card’,
  hostDirectives: [TooltipDirective],
  template: ``,
})
export class BaseCardComponent {}

@Component({
  selector: ‘app-fancy-card’,
  hostDirectives: [TooltipDirective], // duplicate — now de-duplicated automatically
  template: ``,
})
export class FancyCardComponent extends BaseCardComponent {}

m) ⚠️ Drop support for TypeScript 5.9 - PR

Angular 22 now requires TypeScript 6.0 or later. TypeScript 5.9 and older are no longer supported. Make sure to update your TypeScript dependency when upgrading.

n) ⚠️ `ComponentFactoryResolver` & `ComponentFactory` removed - PR

ComponentFactoryResolver and ComponentFactory have been completely removed from the API surface. These were deprecated long ago in favor of passing component classes directly.

// Before ❌ — using the factory pattern
const factory = this._resolver.resolveComponentFactory(MyComponent);
const componentRef = viewContainerRef.createComponent(factory);

// After ✅ — pass the component class directly
const componentRef = viewContainerRef.createComponent(MyComponent);

// Or use the standalone function:
const componentRef = createComponent(MyComponent, { environmentInjector });

If you’re still using ComponentFactoryResolver anywhere — in dynamic component loading, lazy modules, or testing utilities — this is the migration you need to make.

o) Bootstrap via `ApplicationRef` with config - PR

ApplicationRef.bootstrap() now accepts a configuration object as its second argument. The type has been tightened — it no longer accepts any, so you need to pass a proper non-nullable element.

// Before — second arg was loosely typed as `any`
appRef.bootstrap(AppComponent, document.getElementById(’app’));

// Angular 22 — stricter typing, element must be non-nullable
const rootEl = document.getElementById(’app’);
if (rootEl) {
  appRef.bootstrap(AppComponent, rootEl);
}

This is a breaking change if you were passing a potentially nullable element without checking first.

p) Synchronous Values for Stream Resources - PR

Stream resources (resource() with a stream loader) previously required the loader to return a PromiseLike>>. That async requirement meant the resource always started in a loading state — even when the data was available immediately.

Thanks for reading Angular: From Zero to Expert! This post is public so feel free to share it.

This was a real problem for SSR scenarios. When you’re trying to cache resource values in TransferState, the resource needs to set its value synchronously. Otherwise, it enters loading state on the client, which destroys the server-hydrated DOM before the value arrives.

The ResourceStreamingLoader type now accepts three return types:

// New type signature
type ResourceStreamingLoader = (
  param: ResourceLoaderParams
) => Signal>       // ← NEW: synchronous
   | PromiseLike>>  // existing async
   | undefined;                                   // ← NEW: skip loading

What this enables:

@Component({
  template: `
    @if (weather.value(); as data) {
      {{ data.temperature }}°C in {{ data.city }}
    }
  `
})
export class WeatherComponent {
  private _city = input.required();
  private _cache = inject(TransferStateCache);

  weather = resource({
    params: this._city,
    stream: ({ params: city }) => {
      // Check cache first — returns synchronously if cached
      const cached = this._cache.get(`weather-${city}`);
      if (cached) {
        // Resource is immediately 'resolved', no loading flicker
        return signal({ value: cached });
      }

      // Fall back to async fetch
      return this._fetchWeather(city);
    },
  });

  private async _fetchWeather(
    city: string
  ): Promise>> {
    const response = await fetch(`/api/weather?city=${city}`);
    const data: WeatherData = await response.json();
    return signal({ value: data });
  }
}

The key win: rxResource with synchronous observables (like of(value)) now resolves immediately after a tick instead of requiring await appRef.whenStable(). This makes SSR hydration seamless — the client picks up the cached value without any loading state flash.

q) Support Bootstrapping Under Shadow Roots - PR

Angular applications can now be bootstrapped inside a Shadow DOM root. Previously, bootstrapApplication assumed it was working with the document’s root — which broke when you tried to embed an Angular app inside a web component’s shadow root.

This is a big deal for micro-frontend architectures and web component integration scenarios:

// Bootstrap Angular inside a shadow root
const shadowRoot = hostElement.attachShadow({ mode: 'open' });

const appDiv = document.createElement('div');
appDiv.id = 'angular-app';
shadowRoot.appendChild(appDiv);

bootstrapApplication(AppComponent, {
  ...appConfig,
  // Angular now correctly scopes to the shadow root
  // instead of assuming document-level access
});

This means Angular can coexist with other frameworks on the same page without style or DOM conflicts, each living in its own shadow boundary. If you’re building micro-frontends or embedding Angular widgets in non-Angular pages, this removes a significant barrier.

r) The New `@Service` Decorator - PR

This is a big one. Angular now has a dedicated @Service decorator that’s purpose-built for the most common use case: defining a singleton service available across your entire app.

@Injectable has been around since Angular 2, and it carries a lot of historical baggage. Most developers just want to create a service that’s providedIn: 'root', uses inject() for dependencies, and doesn’t need the complex provider configurations (useClass, useValue, useFactory, etc.). Yet every time, you have to write @Injectable({ providedIn: 'root' }) — boilerplate that adds noise without adding value.

@Service fixes this by making the common case the default. Here’s what’s different:

providedIn: 'root' by default. No configuration needed for the 90% case. If you want to provide the service yourself, set autoProvided: false.
No constructor-based injection. Only the inject() function is supported. This aligns with where Angular has been heading for a while now.
Simplified factory support. Instead of the complex useClass/useValue/useExisting/useFactory signature from @Injectable, @Service supports a single factory function.

// Before: @Injectable with boilerplate ❌
import { Injectable, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable({ providedIn: 'root' })
export class PostService {
  private readonly _httpClient = inject(HttpClient);

  getUserPosts(userId: string) {
    return this._httpClient.get(`/api/posts/${userId}`);
  }
}

// After: @Service — clean and intentional ✅
import { Service, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Service()
export class PostService {
  private readonly _httpClient = inject(HttpClient);

  getUserPosts(userId: string) {
    return this._httpClient.get(`/api/posts/${userId}`);
  }
}

The difference looks small in a single file, but across a codebase with hundreds of services, the intent becomes much clearer. @Service() says “this is a singleton service” without any ceremony.

When you don’t want automatic root-level providing — say, for a service scoped to a specific component or route — you opt out explicitly:

@Service({ autoProvided: false })
export class PanelStateService {
  private readonly _isOpen = signal(false);

  readonly isOpen = this._isOpen.asReadonly();

  toggle(): void {
    this._isOpen.update((open) => !open);
  }
}

And if you need a custom factory (the equivalent of useFactory in @Injectable):

@Service({
  factory: () => {
    const config = inject(AppConfig);
    const http = inject(HttpClient);
    return new ApiService(config.apiBaseUrl, http);
  },
})
export class ApiService {
  constructor(
    private readonly _baseUrl: string,
    private readonly _http: HttpClient
  ) {}

  get(path: string) {
    return this._http.get(`${this._baseUrl}${path}`);
  }
}

One thing worth noting: @Service enforces inject()-only dependency resolution. If you try to use constructor parameters for DI, the compiler will throw a SERVICE_CONSTRUCTOR_DI error. This is intentional — the Angular team is pushing the ecosystem toward inject() as the standard pattern, and @Service draws that line clearly.

@Injectable isn’t going anywhere. It’s still fully supported for cases that need its flexibility. But for new services, @Service is the cleaner, more opinionated choice.

s) Testability Now Uses PendingTasks for Stability - PR

Angular’s Testability service — the one that powers whenStable() for tools like Protractor and E2E testing frameworks — has been updated to use PendingTasks as its stability indicator. This is a significant step toward making the testing infrastructure work seamlessly in zoneless applications.

Here’s the backstory. Angular’s stability concept has historically been tied to Zone.js. The Testability.isStable() method checked whether the NgZone was stable and had no pending macrotasks. That worked fine when Zone.js was the only game in town, but it completely broke for zoneless apps — there was no Zone to check.

Meanwhile, Angular has been building PendingTasks as a zone-agnostic way to track async work. The Router and HttpClient already contribute to PendingTasks. This commit connects the dots: Testability now checks PendingTasks in addition to Zone stability.

The behavior depends on your setup:

Zoneless apps (no Zone.js present): PendingTasks is used automatically. whenStable() resolves when there are no pending tasks — no configuration needed.
Zone.js apps: The old Zone-based stability check still works by default. You can opt into PendingTasks-based stability through provideProtractorTestingSupport().

// Zoneless app — PendingTasks stability works automatically ✅
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(),
    provideExperimentalZonelessChangeDetection(),
    // whenStable() now works correctly without Zone.js
  ],
};

// Zone.js app — opt into PendingTasks stability explicitly
import { provideProtractorTestingSupport } from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(),
    provideProtractorTestingSupport({
      usePendingTasksForStability: true,
    }),
  ],
};

The isStable() method now evaluates three conditions instead of two:

// Internal logic (simplified)
isStable(): boolean {
  return (
    this._isZoneStable &&
    !this._ngZone.hasPendingMacrotasks &&
    (!this._usePendingTasks || !this.pendingTasksInternal.hasPendingTasks)
  );
}

What this means for you in practice: if you’re migrating to zoneless and your E2E tests use whenStable() (directly or through a testing framework), they’ll now work correctly. The Router navigation, HttpClient requests, and any custom PendingTasks usage will all be tracked as part of application stability.

t) `injectAsync` — lazy-load and inject services on demand - PR

Here’s the thing about lazy loading in Angular: we’ve had lazy routes for ages, but lazy-loading services has always been awkward. You’d typically need to grab an EnvironmentInjector, dynamically import the service class, then manually call injector.get(). It worked, but it wasn’t ergonomic.

injectAsync is a new helper function exported from @angular/core that streamlines this pattern. It returns a function that, when called, resolves to an instance of the lazily-loaded service — fully wired through DI.

import { Component, injectAsync } from '@angular/core';

@Component({
  selector: 'app-dashboard',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    
  `,
})
export class DashboardComponent {
  // Returns a function: () => Promise
  private _chartService = injectAsync(
    () => import('./chart.service').then((m) => m.ChartService),
  );

  async loadChart(): Promise {
    const chartService = await this._chartService();
    chartService.render();
  }
}

u) SSR resource caching - PR

Angular’s resource() and rxResource() now support a new id option that enables automatic caching through TransferState. This is the missing piece for SSR + signals: data fetched on the server gets serialized into the HTML, and when the client hydrates, the resource resolves synchronously from the cache instead of making a redundant network request.

Here’s the problem this solves. Without caching, your SSR flow looks like:

Server renders → resource fetches data → HTML sent to client
Client hydrates → resource fetches the same data again → flash of loading state

With the id option, step 2 becomes: client hydrates → resource reads from TransferState → instant resolution, no network call, no loading flicker.

import { resource } from '@angular/core';
import { inject } from '@angular/core';

@Component({
  selector: 'app-product-detail',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    @if (product.status() === 'resolved') {
      {{ product.value().name }}
      {{ product.value().description }}
    }
  `,
})
export class ProductDetailComponent {
  private _productId = input.required();
  private _http = inject(HttpClient);

  product = resource({
    params: () => ({ id: this._productId() }),
    loader: ({ params }) =>
      firstValueFrom(this._http.get(`/api/products/${params.id}`)),
    id: 'product-detail', // ← enables TransferState caching
  });
}

The id is a string added to BaseResourceOptions. It serves as the TransferState key. When the resource resolves on the server, the value is written to TransferState under that key. On the client, if a matching key exists in TransferState, the resource skips the loader entirely and resolves synchronously with the cached value.

This also works with rxResource():

import { rxResource } from '@angular/core/rxjs-interop';

export class DashboardComponent {
  private _http = inject(HttpClient);

  metrics = rxResource({
    stream: () => this._http.get('/api/metrics'),
    id: 'dashboard-metrics',
  });
}

This is different from HttpClient‘s transferCache option (which caches HTTP responses at the interceptor level). The id option works at the resource level, meaning it caches the final resolved value regardless of how you fetched it — HTTP, WebSocket, IndexedDB, whatever your loader does.

One thing to note: you need provideClientHydration() in your app config for TransferState to work. If you’re already using SSR with hydration, you likely have this set up.

Templates & Compiler

a) Support comments in HTML elements - PR

Angular’s template parser now supports HTML comments inside elements.


Subscribe to codigotipado!

b) ⚠️ Compile-time diagnostic for duplicate selectors (NG8023) - PR

Angular now throws a compile-time error when multiple components or directives share the same selector within the same scope. Before this, the behavior was undefined — sometimes one would win, sometimes you’d get subtle bugs that were painful to track down.

The new diagnostic NG8023 catches this at build time:

// This now throws NG8023 at compile time
@Component({
  selector: ‘app-card’,
  template: `Card A`,
})
export class CardAComponent {}

@Component({
  selector: ‘app-card’, // Duplicate selector!
  template: `Card B`,
})
export class CardBComponent {}

error NG8023: Multiple components match node with selector "app-card".

If you have duplicate selectors in your codebase, you’ll need to rename one of them. This is a breaking change, but honestly it’s catching a bug you already had.

c) Warning for `@defer` prefetch without main trigger - PR

The compiler now emits a warning when you use prefetch on a @defer block without specifying a main trigger. This catches a common mistake — if there’s no trigger to actually load the deferred content, the prefetch is pointless.


@defer (prefetch on idle) {
  
}


@defer (on viewport; prefetch on idle) {
  
}

This is a compile-time warning, not an error — your app will still build. But it’s a strong hint that something’s off in your defer configuration.

d) ⚠️ Safe Navigation Now Correctly Narrows Nullables - PR

This one's been a long time coming. Since 2020, Angular's safe navigation operator (?.) in templates didn't actually narrow types the way TypeScript does in regular code. That meant you couldn't rely on ?. checks to eliminate null | undefined from subsequent expressions — the type system just ignored the narrowing.

BREAKING CHANGE: This will trigger nullishCoalescingNotNullable and optionalChainNotNullable diagnostics on existing projects. If you're seeing a flood of new warnings after updating, you can temporarily disable those two diagnostics in your tsconfig.json:

// tsconfig.json
{
  "angularCompilerOptions": {
    "extendedDiagnostics": {
      "checks": {
        "nullishCoalescingNotNullable": "suppress",
        "optionalChainNotNullable": "suppress"
      }
    }
  }
}

Or, if you want to disable narrowing entirely (not recommended long-term):

{
  "angularCompilerOptions": {
    "strictSafeNavigationTypes": false
  }
}

Here’s what this actually means in practice:

// Before: Angular didn't narrow after ?. — this compiled fine even though it's redundant
@Component({
  template: `
    @if (user?.name) {
      
      {{ user?.name ?? 'fallback' }}  
    }
  `
})

// After ✅: Angular correctly narrows — you'll get a warning about the unnecessary ??
@Component({
  template: `
    @if (user?.name) {
      
      {{ user.name }}  
    }
  `
})

The ng update migration (covered below in Migrations) will automatically disable these diagnostics so you can update without being blocked, then fix them at your own pace.

e) ⚠️ Optional chaining now returns `undefined` instead of `null` - PR

This is a big one. Angular’s template compiler has historically treated the safe navigation operator (?.) differently from standard JavaScript/TypeScript. In vanilla JS, foo?.bar returns undefined when foo is nullish. But Angular templates used to return null. That inconsistency has been a source of subtle bugs for years — particularly when comparing values in templates or passing them to functions that distinguish between null and undefined.

Angular expressions with optional chaining now correctly return undefined, aligning template behavior with the JavaScript specification.





{{ user?.address?.city }}


@if (user?.address?.city === undefined) {
  No city provided
}

Migration path: If you have code that explicitly checks for null from optional chaining results, you’ll need to update those checks. The Angular team provides two escape hatches:

$null() magic function — wrap any expression to preserve the old behavior:


{{ $null(user?.address?.city) }}

legacyOptionalChaining compiler option — a project-wide flag in tsconfig.json:

{
  "angularCompilerOptions": {
    "legacyOptionalChaining": true
  }
}

The legacyOptionalChaining flag is meant as a temporary migration aid. It won’t stick around forever — plan to remove it once you’ve audited your templates.

What’s interesting is how the linker handles backward compatibility: libraries compiled with Angular < 22 automatically get the legacy behavior applied, so you don’t need to worry about third-party packages breaking.

f) Node.js 26.0.0 support - PR

g) External TCBs with copied content in specific mode - PR

Enables better type-checking accuracy when working with templates in external files.

Forms

Signal Forms got a lot of love in this release. Learn more about Angular Signal Forms here.

a) `debounce()` with ‘blur’ option - PR

The debounce() rule in Signal Forms now supports a 'blur' mode. Instead of debouncing by time, validation only fires when the field loses focus:

import { form, debounce, validateAsync } from ‘@angular/forms/signals’;

const myForm = form(data, (path) => {
  // Validation fires only when the user leaves the field
  debounce(path.username, ‘blur’);

  validateAsync(path.username, {
    params: (ctx) => ({ username: ctx.value() }),
    factory: (params) => httpResource(() => `/api/check-username?u=${params.username}`),
    onSuccess: (result) => (result.taken ? { usernameTaken: true } : null),
  });
});

This is perfect for fields where partial values are meaningless — IBANs, coupon codes, usernames. No point validating “Lond” against an API when the user clearly isn’t done typing.

b) `reloadValidation()` for Signal Forms - PR

You can now manually trigger async validation on a signal form field with reloadValidation(). This is useful when external state changes and you need to re-validate without the user modifying the field — think of a coupon code field that should re-validate when the cart contents change.

import { form, validateAsync, reloadValidation } from ‘@angular/forms/signals’;

@Component({
  selector: ‘app-checkout’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    
    @if (couponField.errors()?.invalidCoupon) {
      This coupon is no longer valid for your cart
    }
    
  `,
})
export class CheckoutComponent {
  private readonly _cartService = inject(CartService);

  protected readonly data = signal({ coupon: ‘’ });

  protected readonly checkoutForm = form(this.data, (path) => {
    validateAsync(path.coupon, {
      params: (ctx) => ({ code: ctx.value(), cartTotal: this._cartService.total() }),
      factory: (params) =>
        httpResource(() => `/api/validate-coupon?code=${params.code}&total=${params.cartTotal}`),
      onSuccess: (result) => (result.valid ? null : { invalidCoupon: true }),
    });
  });

  protected get couponField() {
    return this.checkoutForm.controls.coupon;
  }

  onCartChanged(): void {
    // Cart changed — re-validate the coupon without the user touching the field
    reloadValidation(this.checkoutForm.controls.coupon);
  }
}

c) Debounce option for `validateAsync` and `validateHttp` - PR

Async validators now accept a debounce configuration directly, so you don’t always need a separate debounce() rule:

// validateAsync with built-in debounce
validateAsync(path.city, {
  debounce: 500,
  params: (ctx) => ({ city: ctx.value() }),
  factory: (params) => httpResource(() => `/api/validate-city?name=${params.city}`),
  onSuccess: (result) => (result.valid ? null : { invalidCity: true }),
});

// validateHttp with built-in debounce — same pattern
validateHttp(path.email, {
  debounce: 300,
  request: (ctx) => `/api/check-email?email=${encodeURIComponent(ctx.value())}`,
  onSuccess: (response) => (response.available ? null : { emailTaken: true }),
});

Before this, you had to pair every async validator with a separate debounce() call. Now it’s a single declaration. The debounce option accepts a number (milliseconds) or 'blur' — same as the standalone debounce() rule.

d) `FieldState.getError()` - PR

A new convenience method to retrieve a specific error from a field’s validation state:

const emailError = fieldState.getError(’email’);
// Returns the error value or undefined

e) Support binding `number | null` to - PR

Signal Forms now properly handle binding number | null values to text inputs. Before this, you’d get type errors or unexpected behavior when a numeric field could be null.

type ProductForm = {
  name: string;
  price: number | null;  // nullable numeric field
  discount: number | null;
};

const data = signal({
  name: ‘Widget’,
  price: 29.99,
  discount: null, // no discount yet
});

const productForm = form(data, (path) => {
  validate(path.name, required);
});

When the value is null, the input displays empty. When the user types a number, it’s parsed back to number. Clean round-trip for nullable numeric fields.

f) `ngNoCva` opt-out for ControlValueAccessors - PR

A new ngNoCva attribute lets you opt out of ControlValueAccessor binding on specific elements. This is useful when you have a custom form control but don’t want Angular’s CVA machinery to interfere with certain child elements.

g) Template & reactive support for FVC - PR

Form Validation Controls (FVC) now work with both template-driven and reactive forms approaches, expanding the interop surface between Signal Forms and the existing form systems.

// Template-driven: FVC works with ngModel
@Component({
  selector: ‘app-profile’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [FormsModule, SignalFormsModule],
  template: `
    
    @if (nameValidation.errors()?.required) {
      Name is required
    }
  `,
})
export class ProfileComponent {
  protected name = ‘’;
  protected readonly nameValidation = fieldValidation(/* ... */);
}

// Reactive: FVC works with FormControl
@Component({
  selector: ‘app-settings’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [ReactiveFormsModule, SignalFormsModule],
  template: `
    
  `,
})
export class SettingsComponent {
  protected readonly emailControl = new FormControl(’‘);
  protected readonly emailValidation = fieldValidation(/* ... */);
}

h) ⚡ Lazily instantiate signal form fields - PR

A performance improvement that defers the instantiation of signal form fields until they’re actually needed. For large forms with many fields, this reduces the initial creation cost.

i) Shim Legacy NG_VALIDATORS into parseErrors for CVA Mode - PR

Signal Forms CVA (ControlValueAccessor) interop mode now properly bridges legacy NG_VALIDATORS into the new parseErrors system. If you have existing custom validators registered through the legacy NG_VALIDATORS token, they’ll now work correctly when used alongside Signal Forms CVA mode.

This is about backward compatibility. As the Angular team builds out Signal Forms, they need to ensure that existing form infrastructure doesn’t break. This shim means you can incrementally adopt Signal Forms without rewriting all your custom validators at once:

// Your existing validator directive still works with Signal Forms CVA mode
@Directive({
  selector: '[appCustomValidator]',
  providers: [
    {
      provide: NG_VALIDATORS,
      useExisting: CustomValidatorDirective,
      multi: true,
    },
  ],
})
export class CustomValidatorDirective implements Validator {
  validate(control: AbstractControl): ValidationErrors | null {
    return control.value?.length > 10 ? { tooLong: true } : null;
  }
}

// These legacy validators now correctly surface in Signal Forms' parseErrors
// No migration needed — the shim handles the bridging automatically

j) 🎉 Signal forms APIs graduate to public API - PR

This is the big one. Signal-based forms — which have been in developer preview — are now part of Angular's stable public API. This means the APIs are subject to Angular's semantic versioning guarantees and won't have breaking changes outside major versions.

Read full guide about Angular Signal Forms here.

k) ⚡ Performance: shallow array equality for reactivity - PR

Signal forms now use shallow array equality checks when determining whether reactive values have changed. Previously, any mutation to an array (even if the contents were identical) would trigger downstream recomputation. Now, if the array elements are the same by reference, the signal won’t notify dependents.

This reduces unnecessary change detection cycles in forms with array-based controls (like dynamic field lists or multi-select values).

l) ⚡ Performance: shortcut deepSignal writes if value is unchanged - PR

When writing to a deep signal (nested form state), the framework now short-circuits if the new value is identical to the current one. No notification, no recomputation, no template re-render. This is a targeted optimization for forms where programmatic resets or patches might write the same value back.

m) ⚠️ `min` and `max` validation rules no longer accept strings - PR

The min and max validation rules in signal forms no longer accept string values. Bound values must be number | null.

// Before — strings were silently accepted ❌
this._fb.field(0, { validators: [min('5')] });

// After — must be number or null ✅
this._fb.field(0, { validators: [min(5)] });

If you were passing string values (perhaps from template bindings), you’ll need to parse them to numbers first.

HTTP

a) ⚠️ FetchBackend is now the default HTTP backend - PR

provideHttpClient() now uses FetchBackend by default instead of HttpXhrBackend. The Fetch API is more modern, supports streaming, and aligns with where the web platform is heading.

What this means:

Upload progress reports are no longer available by default (Fetch API limitation)
If you need upload progress, use withXhr():

// Before (Angular 21) — XHR was the default
provideHttpClient()

// Angular 22 — Fetch is the default. Same call, different backend.
provideHttpClient()

// If you need XHR (for upload progress):
provideHttpClient(withXhr())

There’s a migration schematic that adds withXhr() where needed. withFetch() is now deprecated since Fetch is the default — you can safely remove it.

b) `reportUploadProgress` & `reportDownloadProgress` replace `reportProgress` - commit 7c8c334

The monolithic reportProgress option on HTTP requests is now deprecated. In its place, two granular options give you explicit control over which direction of progress you want to track:

// Before — reported both upload AND download progress ❌ (deprecated)
this._http.post('/upload', formData, {
  reportProgress: true,
  observe: 'events',
});

// After — explicit about what you're tracking ✅
this._http.post('/upload', formData, {
  reportUploadProgress: true,
  observe: 'events',
});

// Or for downloads:
this._http.get('/large-file', {
  reportDownloadProgress: true,
  observe: 'events',
});

// Or both:
this._http.post('/upload-with-response', formData, {
  reportUploadProgress: true,
  reportDownloadProgress: true,
  observe: 'events',
});

This split makes intent clearer and avoids the overhead of tracking progress in a direction you don’t care about. Most file upload UIs only need upload progress; most download UIs only need download progress. Now you can be explicit.

Router

a) `withComponentInputBinding` options - PR

withComponentInputBinding() now accepts an optional config to control which router sources bind to your component inputs:

// Disable query param binding — only path params and route data bind
provideRouter(routes, withComponentInputBinding({ queryParams: false }));

Before this, it was all or nothing. Now you can prevent query parameters from overriding your component inputs — which is a real hygiene improvement since query params are user-controlled. I wrote a full article about this one: Selective Component Input Binding in Angular 22.

b) `browserUrl` input support for router links - PR

Router links now support a browserUrl input that lets you display a different URL in the browser’s address bar than the actual route being navigated to. This was already possible with router.navigateByUrl() via NavigationBehaviorOptions, but now it works declaratively in templates.

@Component({
  selector: ‘app-product-list’,
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [RouterLink],
  template: `
    @for (product of products(); track product.id) {
      
      
        {{ product.name }}
      
    }
  `,
})
export class ProductListComponent {
  products = input.required();
}

The browserUrl input accepts a string or UrlTree. This is useful for SEO-friendly URLs, vanity URLs, or when your internal route structure doesn’t match the URL you want users to see and share. It works on both elements and non-anchor elements with [routerLink].

c) ⚠️ `provideRoutes()` removed - PR bdb6ae9

The deprecated provideRoutes() function has been removed. Use provideRouter() or the ROUTES multi token instead:

// Before ❌
provideRoutes(myRoutes)

// After ✅
provideRouter(myRoutes)

// Or if you need the multi-token approach:
{ provide: ROUTES, useValue: myRoutes, multi: true }

d) `unmatchedInputBehavior` option for `componentInputBinding` - PR

When you enable withComponentInputBinding() in the router, route parameters and query params are automatically bound to component inputs. But what happens when a route parameter doesn’t match any input on the component? Previously, it was silently ignored.

The new unmatchedInputBehavior option lets you control this:

import { provideRouter, withComponentInputBinding } from '@angular/router';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withComponentInputBinding({ unmatchedInputBehavior: 'warn' }),
    ),
  ],
};

This is useful for catching typos in route configurations or detecting when route params change names but components haven’t been updated. In development, setting this to 'warn' or 'error' helps catch mismatches early.

Rendering & Platform

a) ⚠️ Hammer.js integration removed - PR

The built-in Hammer.js integration has been completely removed. If you’re using gesture events like (swipe), (pinch), (rotate), etc., you’ll need to implement your own gesture handling or use a third-party library directly.

// Before ❌ — Angular handled Hammer.js integration
import { HammerModule } from ‘@angular/platform-browser’;

// After ✅ — Use Hammer.js directly or switch to Pointer Events
// Install hammerjs yourself and set it up manually,
// or migrate to native pointer events

For most apps, the Pointer Events API is the modern replacement.

b) Incremental Hydration Is Now the Default - PR

Incremental hydration is no longer opt-in — it’s the default behavior. Previously, you had to explicitly enable it. Now, when your application uses SSR with hydration, Angular will incrementally hydrate components as they become needed rather than hydrating the entire page at once.

What does this mean in practice? Your SSR pages will become interactive faster because Angular only hydrates the components that the user is actually interacting with. A component at the bottom of a long page won’t be hydrated until the user scrolls to it (or it’s triggered by some other interaction).

// Before: you had to explicitly opt in
// provideClientHydration(withIncrementalHydration())

// After ✅: incremental hydration is on by default
// Just use provideClientHydration() — incremental behavior is included
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideClientHydration(),  // incremental hydration is now default
  ],
};

You can still use @defer blocks to control hydration triggers:

@Component({
  template: `
    
      
    

    
      

      @defer (on viewport) {
          
      }

      @defer (on interaction) {
          
      }
    
  `
})
export class PageComponent {}

This is a meaningful performance win for content-heavy pages. The initial Time to Interactive (TTI) drops because Angular isn’t spending time hydrating components the user hasn’t reached yet.

Developer Tooling

a) Angular DI Graph In-Page AI Tool - PR

Angular now ships a built-in AI tool that exposes the dependency injection graph at runtime. This is part of the broader push to make Angular applications introspectable by AI assistants and developer tools.

The DI graph tool lets AI-powered debugging assistants (think: Copilot, Gemini, or custom MCP tools) query the injector hierarchy, understand which services are provided where, and trace dependency chains — all from within the running application.

b) Register AI Runtime Debugging Tools - PR

Closely related to the DI graph tool above, this commit establishes the infrastructure for registering AI runtime debugging tools in Angular. It provides the foundation that allows Angular to expose runtime information (component trees, signal states, DI graphs) to external AI tools.

Think of it as the plumbing that makes the DI graph tool (and future AI tools) possible. The framework now has a standardized way to register and expose debugging capabilities that AI assistants can consume.

c) Enhanced Profiling with Documentation URLs - PR

Angular’s profiling output now includes links to relevant documentation. When you’re profiling your application and see a particular operation taking time, the profiler will point you directly to the docs that explain what that operation does and how to optimize it.

It’s a small but thoughtful improvement. Instead of seeing a cryptic profiling label and having to search the docs yourself, you get a direct link. This is especially helpful for developers who are newer to Angular’s internals.

d) `provideWebMcpTools` — MCP integration for Angular apps - PR

Angular is going all-in on AI tooling. provideWebMcpTools is a new provider function that registers WebMCP tools directly through Angular’s dependency injection system. MCP (Model Context Protocol) is the open standard that lets AI assistants — Claude, Copilot, Cursor, etc. — interact with your running application: inspecting component state, triggering actions, querying data.

Here’s what makes this interesting: the tools are tied to the lifecycle of the Injector they’re provided to. They register automatically when the environment initializes and unregister when the injector is destroyed. And the execute function runs in the injection context of that injector — meaning you can inject() any dependency inside it.

import { provideWebMcpTools } from '@angular/core';
import { ApplicationConfig } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideWebMcpTools([
      {
        name: 'getUserCart',
        description: 'Returns the current user cart items with quantities and prices',
        inputSchema: { type: 'object', properties: {} },
        execute: async () => {
          const cartService = inject(CartService);
          const items = cartService.items();

          return {
            content: [{
              type: 'text',
              text: JSON.stringify(items),
            }],
          };
        },
      },
    ]),
  ],
};

The execute function receives two arguments: the parsed args (typed from your inputSchema) and a WebMcpClient object containing an AbortSignal for cancellation support.

What’s particularly powerful is combining this with route-level providers and withExperimentalAutoCleanupInjectors. Tools register when the user navigates to a route and automatically unregister when navigating away:

import { provideRouter, withExperimentalAutoCleanupInjectors } from '@angular/router';
import { provideWebMcpTools } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      [
        {
          path: 'admin',
          component: AdminDashboardComponent,
          providers: [
            provideWebMcpTools([
              {
                name: 'getSystemMetrics',
                description: 'Returns current system health metrics (only available on admin page)',
                inputSchema: {
                  type: 'object',
                  properties: {
                    timeRange: { type: 'string', enum: ['1h', '24h', '7d'] },
                  },
                },
                execute: async (args) => {
                  const metrics = inject(MetricsService);
                  const data = await metrics.fetch(args.timeRange);

                  return { content: [{ type: 'text', text: JSON.stringify(data) }] };
                },
              },
            ]),
          ],
        },
      ],
      withExperimentalAutoCleanupInjectors(),
    ),
  ],
};

When the user navigates to /admin, the getSystemMetrics tool becomes available to AI assistants. Navigate away, and it’s gone. No manual cleanup needed.

Under the hood, provideWebMcpTools is a thin wrapper — it calls makeEnvironmentProviders with a provideEnvironmentInitializer that iterates over your tool descriptors and calls declareWebMcpTool for each one.

e) `declareWebMcpTool` — the low-level imperative API - PR

While provideWebMcpTools is the ergonomic, declarative approach, declareWebMcpTool is the lower-level primitive it’s built on. This function immediately registers a single WebMCP tool and ties its lifecycle to the current (or provided) Injector.

import { declareWebMcpTool } from '@angular/core';
import type { WebMcpToolDescriptor } from '@angular/core';

@Component({
  selector: 'app-chat',
  template: `...`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ChatComponent {
  private _chatService = inject(ChatService);

  constructor() {
    // Registers the tool in the current injection context.
    // Automatically unregistered when this component's injector is destroyed.
    declareWebMcpTool({
      name: 'sendMessage',
      description: 'Sends a message in the active chat conversation',
      inputSchema: {
        type: 'object',
        properties: {
          message: { type: 'string' },
          channel: { type: 'string' },
        },
      },
      execute: async (args) => {
        await this._chatService.send(args.channel, args.message);
        return { content: [{ type: 'text', text: `Message sent to #${args.channel}` }] };
      },
    });
  }
}

The function signature:

declare function declareWebMcpTool(
  tool: WebMcpToolDescriptor,
  injector?: Injector,
): void;

The optional injector parameter lets you register tools outside an injection context — useful for dynamic scenarios where you create tools programmatically.

Key types exported:

WebMcpToolDescriptor — the tool definition (name, description, inputSchema, execute)
WebMcpToolExecute — the execute function type: (args: InferArgsFromInputSchema, client: WebMcpClient) => unknown
WebMcpClient — contains signal: AbortSignal for cancellation

When to use which:

provideWebMcpTools → declarative, multiple tools at once, works in providers arrays
declareWebMcpTool → imperative, single tool, useful inside constructors or afterNextRender

Both are marked @experimental. The JSON Schema types are intentionally not exported from @angular/core — if you need them for complex schemas, add @mcp-b/webmcp-types as a direct dependency.

Language Tooling

a) Template inlay hints - PR

The Angular Language Service now supports inlay hints in templates. These are the subtle inline annotations your editor shows for parameter names, types, and other contextual information. If you use VS Code with the Angular extension, you’ll start seeing type hints directly in your templates.

b) Document Symbols for Angular templates - PR

The language service now provides Document Symbols for Angular templates. This means the Outline view in VS Code (and other editors) will show the structure of your template — components, directives, control flow blocks — making navigation in large templates much easier.

c) Idle timeout support in defer blocks - PR

The language service now understands the new idle timeout syntax in @defer blocks, providing proper autocompletion and diagnostics.

Legacy / Upgrade

a) ⚠️ `getAngularLib`/`setAngularLib` removed - PR

The deprecated getAngularLib and setAngularLib functions have been removed. Use getAngularJSGlobal and setAngularJSGlobal instead:

// Before ❌
import { getAngularLib, setAngularLib } from ‘@angular/upgrade/static’;

// After ✅
import { getAngularJSGlobal, setAngularJSGlobal } from ‘@angular/upgrade/static’;

🛠️ CLI & Build Tooling (`angular/angular-cli`)

@angular/cli

a) ⚡ Faster `ng add` with cached resolution - PR & PR

Two performance improvements to ng add: redundant package version resolution is now avoided, and the root manifest is cached with restricted package exports resolved upfront. If you’ve ever noticed ng add being slow on large monorepos, this should help.

b) MCP devserver custom port support - PR

The MCP (Model Context Protocol) devserver start tool now supports a custom port. This is relevant if you’re using Angular’s AI tooling integration.

c) Chunk Optimization Enabled by Default with Smart Heuristics - PR

The advanced chunk optimization pass — which uses Rollup (or optionally Rolldown) to re-bundle lazy chunks after esbuild — is now enabled by default. Previously, you had to explicitly opt in via the NG_BUILD_OPTIMIZE_CHUNKS environment variable. That’s no longer the case.

Here’s the thing: not every project benefits from this. A small app with one or two lazy routes won’t see meaningful gains, and the extra build step just adds overhead. So the Angular team introduced a heuristic: the optimization only kicks in when your build produces 3 or more lazy chunks. This threshold hits the sweet spot where chunk merging and deduplication actually pay off.

The heuristic counts .js files in the build output that aren’t part of the initial bundle. If that count meets the threshold, the optimization runs automatically. For most medium-to-large apps with multiple lazy-loaded routes, this means smaller total bundle sizes and fewer network requests — without you having to configure anything.

You can still control the behavior through the NG_BUILD_OPTIMIZE_CHUNKS environment variable:

# Force optimization on regardless of chunk count
NG_BUILD_OPTIMIZE_CHUNKS=true ng build

# Disable optimization entirely
NG_BUILD_OPTIMIZE_CHUNKS=false ng build

# Set a custom threshold (e.g., only optimize when 5+ lazy chunks exist)
NG_BUILD_OPTIMIZE_CHUNKS=5 ng build

What happens under the hood: after esbuild generates the initial chunks, Angular feeds them through Rollup (or Rolldown if you’ve opted into it via NG_BUILD_CHUNKS_ROLLDOWN). Rollup analyzes cross-chunk dependencies and merges small chunks that share code, reducing the total number of files the browser needs to fetch for lazy routes.

For a typical app with 10+ lazy routes, this can reduce the number of JS files by 30-50%, which translates directly to fewer HTTP requests and faster route transitions. The build time increase is minimal — usually under a second for the optimization pass itself.

d) Quiet Option for Suppressing Build Noise in Unit Tests - PR

A new quiet option has been added to @angular/build that suppresses build output noise during unit test runs. When running Vitest through the Angular builder, the build system now supports silencing the verbose compilation output that clutters test results.

This is a developer experience improvement. When you’re running tests, you want to see test results — not pages of build logs scrolling by. The quiet option lets the test runner focus the terminal output on what matters: which tests passed, which failed, and why.

e) Stabilized Jasmine-to-Vitest Migration Schematic - PR

The refactor-jasmine-vitest schematic has been marked as stable. This schematic automates the migration from Jasmine test syntax to Vitest, which is now Angular’s recommended testing framework.

If you’ve been holding off on migrating your test suite because the schematic was experimental — that barrier is gone. You can now run it with confidence:

ng generate @schematics/angular:refactor-jasmine-vitest

The schematic handles the mechanical parts of the migration: updating imports, converting Jasmine-specific APIs to their Vitest equivalents, and adjusting configuration files. It won’t rewrite your test logic, but it takes care of the boilerplate changes that make manual migration tedious.

This stabilization signals that the Angular team considers the Vitest migration path production-ready. If you’re still on Karma + Jasmine, this is a good time to start planning the switch.

@angular/build

a) Runtime Zone.js detection in Vitest - PR

The Vitest unit test runner now supports runtime Zone.js detection. If your project still uses Zone.js, the test runner will detect it automatically — no manual configuration needed.

b) ⚠️ `process.env.PORT` takes priority in dev server - PR

The ng serve dev server now gives highest priority to the PORT environment variable. This overrides both angular.json config and the --port CLI flag — including the default 4200.

# This now takes priority over everything
PORT=3000 ng serve
# Even if angular.json says port: 4200 and you pass --port 8080

This is a breaking change if you rely on --port or angular.json to override an environment variable. The priority order is now: PORT env var > --port flag > angular.json.

c) `experimentalPlatform` renamed to `platform` - PR

The experimentalPlatform option in the application builder has been renamed to platform. If you were using this option in your angular.json, update the key name.

d) ⚠️ `istanbul-lib-instrument` is now an optional peer dependency - PR

If you’re using Karma with code coverage, you’ll need to ensure istanbul-lib-instrument is installed as a direct dependency. The ng update schematic handles this automatically.

e) Subresource Integrity (SRI) validation for dynamically loaded modules - PR

This is a security improvement. When you enable subresourceIntegrity: true in your build configuration, Angular already generates integrity hashes for scripts in index.html. But lazy-loaded chunks — the ones fetched at runtime via dynamic import() — weren’t validated.

Now they are. The build system generates integrity metadata for all lazy chunks, and the runtime validates them before execution. If a CDN or proxy tampers with a lazy-loaded module, the browser will reject it.

{
  "architect": {
    "build": {
      "builder": "@angular/build:application",
      "options": {
        "subresourceIntegrity": true
      }
    }
  }
}

What happens under the hood: the build emits a manifest mapping chunk filenames to their SHA-384 hashes. When Angular’s router triggers a lazy import, the runtime fetches the chunk and verifies its integrity against the manifest before evaluating it.

This closes a gap that existed since Angular adopted code splitting. Previously, subresourceIntegrity only protected the initial bundle — the scripts directly referenced in index.html with integrity attributes. Lazy chunks were unprotected. Now the entire application is covered.

For apps served behind CDNs or third-party proxies, this is a meaningful security hardening. It ensures that even if an intermediary modifies a JavaScript chunk in transit, the application will refuse to execute it rather than running potentially malicious code.

@angular/ssr

a) ⚠️ SSR: No more CSR fallback for invalid hosts - PR

The Angular SSR server no longer falls back to Client-Side Rendering when a request fails host validation. Requests with unrecognized Host headers now return a 400 Bad Request. Make sure all valid hosts are configured in the allowedHosts option.

@schematics/angular

a) Strict templates default in generated workspaces - PR

New workspaces generated with ng new now rely on the strict template default. This aligns with the migration that adds strictTemplates to existing projects during ng update.

b) Karma-to-Vitest migration schematic - PR

A new migration schematic that helps you move from Karma to Vitest. Run it during ng update to automatically update your test configuration.

c) Migration to add `istanbul-lib-instrument -` PR

Removed packages

a) ⚠️ `@angular-devkit/architect-cli` removed - PR

The @angular-devkit/architect-cli package is no longer available. The architect CLI tool has been moved to the @angular-devkit/architect package.

b) ⚠️ Experimental Jest and Web Test Runner builders removed - PR

The experimental @angular-devkit/build-angular:jest and @angular-devkit/build-angular:web-test-runner builders have been removed. Vitest is now the recommended test runner going forward.

🎨 Components & CDK (`angular/components`)

📦 Migrations & Schematics (cross-cutting)

a) Add `strictTemplates` to tsconfig during `ng update` — `angular/angular` - PR

When you run ng update, Angular now automatically adds strictTemplates: true to your tsconfig.json if it’s not already there. This has been the recommended setting for a while, and now it’s enforced during migration.

b) Migration schematic for `provideHttpClient` with XHR — `angular/angular` - PR

Since FetchBackend is now the default, a migration schematic is provided to add withXhr() to your provideHttpClient() calls if your app relies on XHR-specific features (like upload progress).

c) Migration for `ChangeDetectionStrategy.Eager` — `angular/angular`

Automatically adds ChangeDetectionStrategy.Eager to components that need it after the default changed to OnPush.

d) Migration for `CanMatchFn` snapshot parameter — `angular/angular` - PR

The currentSnapshot parameter in CanMatchFn and the canMatch method of the CanMatch interface is now required. While the Router already passed this at runtime, existing class implementations must now include the third argument to satisfy the interface. A migration schematic handles this automatically.

// Before ❌ — third parameter was optional
canMatch(route: Route, segments: UrlSegment[]): boolean {
  return true;
}

// After ✅ — currentSnapshot is now required
canMatch(route: Route, segments: UrlSegment[], currentSnapshot: ActivatedRouteSnapshot): boolean {
  return true;
}

e) Karma-to-Vitest migration — `angular/angular-cli`

f) Migration to add `istanbul-lib-instrument` — `angular/angular-cli`

g) Auto-Disable nullishCoalescingNotNullable & optionalChainNotNullable on ng update - PR

When you run ng update to upgrade to this version, the migration will automatically add suppression rules for the nullishCoalescingNotNullable and optionalChainNotNullable diagnostics to your tsconfig.json.

This is the companion migration for the breaking compiler change described above. The idea is simple: don’t block your update with hundreds of new warnings. The migration suppresses them so you can update cleanly, then you can address the warnings incrementally.

After updating, you’ll find this in your tsconfig.json:

{
  "angularCompilerOptions": {
    "extendedDiagnostics": {
      "checks": {
        "nullishCoalescingNotNullable": "suppress",
        "optionalChainNotNullable": "suppress"
      }
    }
  }
}

Once you’ve cleaned up the unnecessary ?. and ?? operators in your templates, remove these suppressions to benefit from the stricter type checking going forward.

h) Auto-Add `strictTemplates` to tsconfig During ng update - PR

When you run ng update to upgrade to Angular 22, a new migration will automatically add strictTemplates: false to your tsconfig.json under angularCompilerOptions — but only if it’s not already set.

Why false? Because Angular 22 is making strictTemplates: true the default compiler behavior. Projects that haven’t explicitly opted into strict templates would suddenly get a wave of new type-checking errors in their templates. The migration preserves the previous implicit behavior by making it explicit, so your update doesn’t break anything.

The migration is smart about it:

If strictTemplates is already set (to true or false), it leaves it alone
If compilerOptions is empty or missing, it skips the file (not a real tsconfig)
If angularCompilerOptions doesn’t exist, it creates the section with strictTemplates: false

// What the migration adds to your tsconfig.json
{
  "compilerOptions": {
    "target": "es2022"
    // ... your existing options
  },
  "angularCompilerOptions": {
    "strictTemplates": false  // ← added by migration
  }
}

After updating, you can (and should) work toward enabling strictTemplates: true at your own pace. Strict template type checking catches real bugs — wrong property names, type mismatches in bindings, missing inputs — that would otherwise only surface at runtime. But the migration ensures you’re not forced into it during the update itself.

i) Model + Output conflict migration - PR

When Angular introduced model() signals, it implicitly created a Change output for two-way binding. But some codebases already had explicit output() declarations with that same name — creating a conflict where the component had duplicate outputs.

This migration automatically detects the pattern and converts it to input() + linkedSignal(), which preserves the reactive behavior without the naming collision.

// Before — broken duplicate outputs ❌
@Component({
  selector: 'app-slider',
  template: '',
})
export class SliderComponent {
  foo = model(0);              // implicitly creates fooChange output
  fooChange = output(); // explicit output — CONFLICT!
}

// After migration ✅
@Component({
  selector: 'app-slider',
  template: '',
})
export class SliderComponent {
  fooInput = input(0, { alias: 'foo' });
  foo = linkedSignal(this.fooInput);
  fooChange = output();
}

The migration handles several cases:

Preserves access modifiers (public, protected, readonly)
Handles generic types (model('initial') → input('initial', {alias: 'bar'}))
Adds input and linkedSignal to the import statement automatically
Only triggers when there’s an actual naming conflict — if your model() doesn’t have a conflicting explicit output, nothing changes

This runs automatically during ng update to Angular 22.

j) Migrate `fakeAsync` to Vitest fake timers - PR

The schematic now automatically converts fakeAsync/tick/flush patterns to Vitest’s native fake timer APIs. Angular’s fakeAsync was a Zone.js-powered utility — in a zoneless Vitest world, you use vi.useFakeTimers() and vi.advanceTimersByTime() instead.

// Before (Jasmine + Zone.js) ❌
it('should debounce input', fakeAsync(() => {
  component.onSearch('angular');
  tick(300);
  expect(component.results().length).toBeGreaterThan(0);
}));

// After (Vitest) ✅
it('should debounce input', () => {
  vi.useFakeTimers();
  component.onSearch('angular');
  vi.advanceTimersByTime(300);
  expect(component.results().length).toBeGreaterThan(0);
  vi.useRealTimers();
});

k) Migrate `fakeAsync`‘s `flush` behavior in `beforeEach` - PR

When fakeAsync with flush() is used inside beforeEach blocks, the schematic now correctly transforms it. This is a common pattern where setup code needs to wait for async initialization to complete before each test.

l) Set up fake timers in `beforeEach` instead of `beforeAll` - PR

The schematic ensures fake timers are set up in beforeEach (per-test isolation) rather than beforeAll (shared across tests). This prevents timer state from leaking between tests — a common source of flaky test suites.

m) Update TSConfig globals during migration - PR

When migrating from Karma to Vitest, the schematic now updates your tsconfig.spec.json to include Vitest’s global type definitions. This ensures TypeScript recognizes vi, describe, it, expect and other Vitest globals without manual configuration.

n) Conditionally install istanbul coverage provider - PR

During the Karma-to-Vitest migration, the schematic now checks if your project uses code coverage and conditionally installs @vitest/coverage-istanbul. This ensures your existing coverage pipeline (Codecov, SonarQube, etc.) continues working without manual intervention.

⚠️ Breaking Changes Summary

⚠️ Deprecations Summary

Thanks for reading so far 🙏

I’d like to have your feedback, so please leave a comment, clap or follow. 👏

Spread the Angular love! 💜

If you liked it, share it among your community, tech bros and whoever you want! 🚀👥

Don’t forget to follow me and stay in the loop: 📱

🔗 LinkedIn
📝 Medium
🎥 YouTube
🐦 Twitter

Thanks for being part of this Angular adventure! 👋😁

injectAsync: Angular's Native Solution for Lazy-Loading Services

Amos Isaila — Wed, 06 May 2026 05:38:15 GMT

If you’ve used ngxtension/inject-lazy, this will feel familiar. But the API is different, and the trade-offs matter.

The Problem

Bundle size. You have a ChartService that pulls in D3, a PdfService that imports pdfjs, or an AnalyticsService that loads a heavy SDK. These services aren’t needed on initial render — maybe they’re triggered by a button click, a route guard, or a conditional feature flag.

With providedIn: 'root', the service class and its dependencies end up in the main bundle regardless of whether the user ever triggers the code path that uses them.

Lazy routes solve this for route-level code splitting. But what about services used within a component that’s already loaded?

Before `injectAsync`: The Manual Approach

@Component({
  selector: 'app-report',
  template: ``,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ReportComponent {
  private _injector = inject(EnvironmentInjector);

  async generate(): Promise {
    const { PdfService } = await import('./pdf.service');
    const pdfService = this._injector.get(PdfService);
    pdfService.createReport();
  }
}

You Can Now Control What Binds to Your Component Inputs in Angular 22

Amos Isaila — Mon, 06 Apr 2026 21:40:13 GMT

The short version

provideRouter(routes, withComponentInputBinding({ queryParams: false }))

That’s it. Query params no longer bind to your component inputs. Path params and route data? Still work fine.

So what was the problem?

Let me show you. Say you have this:

// Route: { path: 'user/:id', component: UserComponent, data: { role: 'admin' } }
// URL: /user/42?tab=settings

@Component({ ... })
export class UserComponent {
  id = input();       // ← from :id
  tab = input();      // ← from ?tab=
  role = input();     // ← from route data
}

All three sources — path params, query params, route data — bind to your inputs automatically. Sounds great until you realize that query params are completely user-controlled. Anyone can type whatever they want in the URL bar.

Picture this:

Angular 22: Debounced Signal

Amos Isaila — Mon, 30 Mar 2026 21:07:21 GMT

Before you start diving into this new topic you can review the full guide of resource() that was introduced in Angular 19.

TL;DR

Angular added a debounced() function that takes a signal and a wait time, and returns a Resource:

signal → debounced(signal, 500) → Resource

The resource’s value() holds the debounced value. Its status tells you whether the value is settled ('resolved'), still waiting ('loading'), or if the source threw ('error'). No RxJS, no setTimeout wrappers, no custom hooks. Just signals in, Resource out.

The Problem

You have a search input. The user types “Tokyo”. Without debouncing, you fire 5 HTTP requests: one per keystroke. That’s wasteful, potentially slow, and can cause race conditions if responses arrive out of order.

The RxJS way:

searchControl.valueChanges.pipe(
  debounceTime(500),
  distinctUntilChanged(),
  switchMap(query => this.http.get(`/api/search?q=${query}`))
).subscribe(results => { ... });

The manual way:

let timer: ReturnType;
function onInput(value: string) {
  clearTimeout(timer);
  timer = setTimeout(() => {
    // now do something with value
  }, 500);
}

Both work. Neither integrates with signals. You end up bridging between observables or callbacks and signals, losing reactivity along the way.

The real gap: there was no signal-native way to debounce a value and get a reactive, composable result back.

The Solution: `debounced()`

The API

import { debounced } from '@angular/core';

const search = signal('');
const debouncedSearch = debounced(() => search(), 500);

debouncedSearch is a Resource. It has everything you’d expect:

debouncedSearch.value() — the debounced value (updates only after 500ms of silence)
debouncedSearch.status() — 'resolved' when settled, 'loading' while waiting, 'error' if the source threw
debouncedSearch.isLoading() — true while a value is pending
debouncedSearch.error() — the error, if the source signal threw

Full Signature

Angular 21.2: Resource Composition via Snapshots

Amos Isaila — Sun, 22 Mar 2026 21:31:59 GMT

Before you start diving into this new topic you can review the full guide of resource() that was introduced in Angular 19.

TL;DR

Angular added three things that let you take a resource, modify its behavior, and get back a real resource.

Resource  →  .snapshot  →  transform it  →  resourceFromSnapshots()  →  Resource

The killer use case? Keep showing old data while new data loads — no more blank screens when switching between items. And it’s a generic utility you write once and reuse everywhere.

PR: feat(core): resource composition via snapshots
Authors: Alex Rickabaugh & Jessica Janiuk
Status: Experimental · Angular 21.2+

Code Repository Example in this article can be found here.

The Problem (in Plain English)

Imagine you have a weather app. The user is looking at London’s weather. They click “Tokyo.” What happens?

Before this PR:

The resource enters “loading” state
value() immediately becomes undefined
The weather card disappears — blank screen, skeleton loader
Tokyo’s data arrives, card re-appears

That flash of empty content feels broken. Users hate it.

You might think: “I’ll just keep the old value around in a separate signal.” Sure, but then you lose the Resource interface. Your workaround doesn’t have .isLoading(), .hasValue(), .status(). It’s a one-off hack that doesn’t compose.

The real problem: there was no way to take a Resource, tweak its behavior, and get back something that’s still a Resource.

Migrating to Signal Forms: The SignalFormControl Bridge in Angular 21.2

Amos Isaila — Sat, 14 Mar 2026 22:14:28 GMT

The Problem Nobody Talks About

Every time Angular introduces a new API, the community gets excited about greenfield projects. “Look how clean this is!” And it is clean. Signal forms are a genuine improvement over reactive forms — less boilerplate, better type safety, signals instead of observables.

But here’s the thing: most of us aren’t building new apps from scratch. We’re maintaining applications with dozens — sometimes hundreds — of reactive forms. Forms that work. Forms that are tested. Forms that have edge cases baked into them over years of production use.

The question isn’t “are signal forms better?” — they are. The question is: how do you get there without rewriting everything?

Angular 21.2 answers this with two interop tools:

SignalFormControl — A signal-based control that extends AbstractControl, so it plugs directly into existing FormGroup and FormArray structures
compatForm — A version of form() that accepts reactive FormControl instances as part of the data model

Both are exported from @angular/forms/signals/compat. Both are experimental. And both solve different migration scenarios.

Understanding the Two Migration Paths

Before diving into code, it’s worth understanding when to use each approach.

SignalFormControl is for when you want to migrate individual fields inside an existing reactive form. You replace one FormControl with a SignalFormControl, and the parent FormGroup doesn’t even notice — it just sees an AbstractControl.

compatForm is for when you want to migrate the form itself to signal forms, but some fields are still FormControl instances that you’re not ready to convert yet.

Think of it this way:

I want to add signal validation to one field in my reactive form → SignalFormControlReactive form → signal field
I want to use form() but keep some existing FormControls → compatFormSignal form → reactive fields

Most teams will start with SignalFormControl because it’s the least disruptive. You change one field, ship it, observe, then do the next one.

`SignalFormControl`: Your First Migration Step

What It Is

SignalFormControl extends AbstractControl — the same base class that FormControl, FormGroup, and FormArray extend. This means it’s a drop-in replacement anywhere Angular’s reactive forms infrastructure expects a control.

Internally, it’s backed by a WritableSignal and a signal forms FieldTree. It translates between the two worlds: when the reactive form reads .value, it gets the signal’s current value. When signal forms validation runs, the results are exposed through the reactive .errors getter.

import { SignalFormControl } from '@angular/forms/signals/compat';

Angular 21.2: What's new

Amos Isaila — Sun, 08 Mar 2026 22:41:51 GMT

1. @angular/animations

2. @angular/build

a) Headless Option for Unit-Test Builder - PR

The unit-test builder now supports a headless option for browser-based tests. You can toggle between headless and headed mode without modifying your Vitest configuration.

ng test --headless=false  # Run with visible browser for debugging
ng test                   # Default: headless

b) Vitest Browser with Playwright OS Theme - PR

When running Vitest browser tests with Playwright, the browser now respects your operating system’s theme (light/dark mode). This means your tests run in an environment that matches your system preferences, which can be relevant for testing theme-dependent UI behavior.

3. @angular/common

a) Outlet Injector Option for `ngTemplateOutlet` - PR

To understand this feature, you first need to understand a quirk of how ngTemplateOutlet works with Angular’s dependency injection.

The problem: templates resolve services from where they’re defined, not where they’re rendered.

Imagine you define an at the root of your component. Inside that template, you try to inject() a service. Angular will look for that service starting from the definition site of the template (where the tag lives in the source code), not from where the template is actually stamped into the DOM via *ngTemplateOutlet.

Here’s a concrete example to make this tangible:

Angular 21.1: What's new

Amos Isaila — Thu, 22 Jan 2026 05:28:43 GMT

1. @angular/common

a) Custom Transformations for Cloudflare and Cloudinary Image Loaders - PR

Adds support for custom transformations to Cloudinary and Cloudflare image loaders via a transform parameter.

You can learn more about How to Configure an image loader for NgOptimizedImage.

b) Custom Transformations for ImageKit and Imgix Loaders - PR

Similar custom transformation support extends to ImageKit and Imgix, two other popular image CDN providers.

You can learn more about How to Configure an image loader for NgOptimizedImage.

Making Sense of Metadata in Angular Signal Forms

Amos Isaila — Mon, 15 Dec 2025 07:11:21 GMT

I’m going to walk you through metadata in Angular Signal Forms using a real project I built—a weather chatbot that checks if cities actually exist before letting you submit the form. No abstract examples, just working code solving actual problems.

Here’s what makes this interesting: the form doesn’t just validate that you typed something. It calls an API to verify the city exists in a weather database, manages the loading state while checking, caches results so you don’t hammer the server, and gives instant feedback. That’s where metadata becomes essential.

The Core Problem

Traditional validation answers simple questions: Is the field empty? Does it match this pattern? But modern forms need smarter behavior. When someone types “Barcelona, Spain,” you want to know:

Does this city exist in your weather database?
Are we currently checking with the server?
Did we already validate this exact combination?
Should we show a spinner?

Your form data is just { city: “Barcelona”, country: “Spain” }. Everything else—the validation state, the API response, the loading indicators—that’s metadata. It’s the difference between what the user entered and what you need to know about what they entered.

Starting With Basic Validation

Let’s look at the foundation. This is pure validation, no async behavior yet:

const cityNameSchema = schema((path) => {
  required(path, { message: ‘City is required’ });
  minLength(path, 2, { message: ‘City must be at least 2 characters’ });
  maxLength(path, 50, { message: ‘City name is too long’ });
});

export const locationSchema = schema((path) => {
  apply(path.city, cityNameSchema);
  apply(path.country, countryNameSchema);
});

This checks structure and format. But it doesn’t verify if Barcelona is real or if someone made it up. For that, you need to talk to an API.

Adding Real Validation

Here’s where it gets interesting. We’re going to validate cities against a weather API as the user types:

Angular 21.0.1: The Missing "Style Link" in Signal Forms 🔗

Amos Isaila — Tue, 02 Dec 2025 05:49:14 GMT

If you’ve been experimenting with the new Signal Forms in Angular 21, you might have noticed something missing. You set up your schemas, you wired up your signals, but when you looked at the DOM... it was clean.

Too clean.

In the old ReactiveForms world, Angular automatically slapped classes like .ng-invalid, .ng-dirty, and .ng-touched onto your inputs. CSS frameworks (like Bootstrap or Material) relied on these hooks to turn borders red or show error icons. With Signal Forms, that automatic behavior was gone—until now.

With the latest merge into core (Commit 7d5c7cf), Angular 21.1 introduces provideSignalFormsConfig. This acts as a bridge between your pure logic signal state and your UI styling.

Let’s look at how this changes the game for our Weather Chatbot, specifically how we can use it to drive a “Tailwind-native” form experience without cluttering our templates.

The “Lazy” Way: Back to Basics

If you just want the old behavior back because you have existing CSS that targets .ng-invalid, the Angular team provided a pre-baked constant.

In your app.config.ts:

import { ApplicationConfig } from ‘@angular/core’;
import { provideSignalFormsConfig } from ‘@angular/forms/signals’;
import { NG_STATUS_CLASSES } from ‘@angular/forms/signals/compat’;

export const appConfig: ApplicationConfig = {
  providers: [
    // 🪄 Magic: Automatically adds ng-valid, ng-invalid, ng-dirty, etc.
    provideSignalFormsConfig({
      classes: NG_STATUS_CLASSES
    })
  ]
};

But we are writing modern Angular. We can do better than legacy compatibility.

The “Pro” Way: Semantic Configuration

This new API allows us to map any CSS class to a predicate function that reads the field state. This is incredibly powerful.

Angular 21: What's new

Amos Isaila — Thu, 20 Nov 2025 20:15:48 GMT

1. @angular/animations

2. @angular/common

a) Zero-Configuration HTTP Services - PR

HTTP services are now automatically provided in the root injector, eliminating the need for explicit provideHttpClient().

import { bootstrapApplication } from '@angular/platform-browser';
import { provideHttpClient } from '@angular/common/http';

// Before
bootstrapApplication(AppComponent, {
  providers: [
    provideHttpClient() // ❌ Required for basic HTTP functionality
  ]
});

// After
bootstrapApplication(AppComponent, {
  providers: [
    // ✅ HTTP services automatically available
  ]
});

Advanced Configuration: For custom interceptors, client configuration, or specific features, continue using provideHttpClient():

Thanks for reading Angular: From Zero to Expert! This post is public so feel free to share it.

bootstrapApplication(AppComponent, {
  providers: [
    provideHttpClient(
      withInterceptors([authInterceptor]),
      withFetch() // Custom features require explicit provider
    )
  ]
});

b) ⚠️ NgComponentOutlet NgModuleFactory Removal - PR

The ngModuleFactory input of NgComponentOutlet was a legacy feature that relied on the deprecated NgModuleFactory class, creating unnecessary complexity and maintenance overhead.

Now ngModuleFactory input from NgComponentOutlet is removed, using only the modern NgModule approach.

Mastering the New debounce() API in Angular 21 Signal Forms

Amos Isaila — Wed, 19 Nov 2025 05:26:50 GMT

The Problem We’ve All Been Ignoring

Here’s something embarrassing: I had a search field in one of my apps that was hitting our ElasticSearch cluster on every single keystroke. A user typing “San Francisco” would trigger 13 API calls. Multiply that by a few hundred concurrent users, and our AWS bill was... let’s just say “uncomfortable.”

The old solution? RxJS operators like debounceTime() scattered throughout components, manual subscription management, and crossing your fingers that you didn’t create a memory leak. It worked, but it felt like duct tape on a leaky pipe.

Signal Forms’ new debounce() rule takes a completely different approach. Instead of managing debouncing at the component level, it’s built directly into the form’s schema definition. The form itself knows when to synchronize user input with your data model.

Building Your Own MCP Server: Angular Best Practices Refactoring Tool - Part 2

Amos Isaila — Sat, 01 Nov 2025 15:42:59 GMT

But here’s where we’re going to do something different from typical tutorials. Instead of building a generic weather API or todo list MCP server, we’re creating something immediately valuable for Angular developers: an MCP server with a powerful refactoring tool that enforces modern Angular and TypeScript best practices.

Angular: From Zero to Expert

NgRx 22: three changes that make SignalStore easier to use

Angular sanitises by default. Here is where that sentence runs out.

The Hour That Doesn’t Exist

Angular 22.2: What's new

🏗️ Framework

Templates & Compiler

a) Templates can access private component members — PR

b) Catch misspelled output bindings — PR

Core & Reactivity

a) Catch errors from dynamically created views — PR

b) Read an element’s Injector from a query — PR

Forms

a) Permanently hidden fields in Signal Forms — PR

b) Signal Forms explain their behavior to AI agents — PR

Router

a) Throw RedirectCommand from guards and resolvers — PR

b) Public containsTree API for URL matching — PR

c) ⚠️ Automatic route-injector cleanup is now stable — PR

d) Load route data with Signals and Resources — PR

Developer Tooling

a) Explicit workspace roots for Angular MCP — PR

b) Test directives without creating a host component — PR

c) WebMCP tools can declare safety annotations — PR

Language Tooling

a) Editor support for @boundary blocks — PR

🛠️ CLI & Build Tooling

Build System

a) Angular Linker moves from Babel to OXC — PR

b) ⚠️ Separate browser and server build statistics — PR

⚠️ Breaking Changes & Deprecations

Thanks for reading so far 🙏

Angular Content Projection Has a Real Design Problem

What signals actually did to Angular lifecycle hooks

Angular 22.1: What's new

🏗️ Framework

Core & Reactivity

a) Custom set option for linkedSignal - PR

Templates & Compiler

a) CSS Variable Namespacing - PR

b) Smaller generated output for foreign components — PR

HTTP

a) More control over the HTTP transfer cache - PR

b) ⚠️ JSONP support is deprecated — PR

Router

a) Nullable inputs for RouterLinkActive - PR

Language Tooling

a) Compile non-exported classes if standalone - PR

b) Typecheck templates requiring inline typecheck blocks - PR

Developer Tooling

a) Deep linking from Chrome’s Performance panel - PR

🛠️ CLI & Build Tooling

a) Angular MCP server enabled by default in new workspaces - PR

b) ⚠️ Deprecation of stringToFileBuffer and fileBufferToString in @angular-devkit/core

c) Share Build Cache Across Git Worktrees - PR

d) Chunk optimization for server builds — PR

e) Faster production optimizations with OXC — PR

f) Much faster localized builds — PR

📦 Migrations & Schematics

a) @Injectable to @Service migration schematic - PR

⚠️ Breaking Changes & Deprecations

1. JSONP Support Deprecated (@angular/common/http)

2. stringToFileBuffer and fileBufferToString Deprecated (@angular-devkit/core)

Thanks for reading so far 🙏

Angular 22: What's new

🏗️ Framework (angular/angular)

Core & Reactivity

a) 🔥 Default change detection is now OnPush - PR

{{ title }}

{{ title }}

b) Signal-native debouncing with debounced() - PR

c) Nested leave animations scoped to component boundaries - PR

d) Special return statuses for resource params - PR

e) TestBed.getLastFixture() - PR

f) Customizable @defer idle behavior - PR & PR

g) Exhaustive type checking for @switch - PR

h) ⚠️ createNgModuleRef removed - PR

i) ⚠️ ChangeDetectorRef.checkNoChanges removed - PR

j) ⚠️ AnimationCallbackEvent.animationComplete signature changed - PR

k) Migration schematic: ChangeDetectionStrategy.Eager - PR

b) Read an element’s `Injector` from a query — PR

a) Throw `RedirectCommand` from guards and resolvers — PR

b) Public `containsTree` API for URL matching — PR

a) Editor support for `@boundary` blocks — PR

a) Custom `set` option for `linkedSignal` - PR

a) Nullable inputs for `RouterLinkActive` - PR

b) ⚠️ Deprecation of `stringToFileBuffer` and `fileBufferToString` in `@angular-devkit/core`

a) `@Injectable` to `@Service` migration schematic - PR

1. JSONP Support Deprecated (`@angular/common/http`)

2. `stringToFileBuffer` and `fileBufferToString` Deprecated (`@angular-devkit/core`)

🏗️ Framework (`angular/angular`)

b) Signal-native debouncing with `debounced()` - PR

e) `TestBed.getLastFixture()` - PR

g) Exhaustive type checking for `@switch` - PR

h) ⚠️ `createNgModuleRef` removed - PR

i) ⚠️ `ChangeDetectorRef.checkNoChanges` removed - PR

k) Migration schematic: `ChangeDetectionStrategy.Eager` - PR

n) ⚠️ `ComponentFactoryResolver` & `ComponentFactory` removed - PR

o) Bootstrap via `ApplicationRef` with config - PR

r) The New `@Service` Decorator - PR

t) `injectAsync` — lazy-load and inject services on demand - PR

c) Warning for `@defer` prefetch without main trigger - PR

e) ⚠️ Optional chaining now returns `undefined` instead of `null` - PR

a) `debounce()` with ‘blur’ option - PR

b) `reloadValidation()` for Signal Forms - PR

c) Debounce option for `validateAsync` and `validateHttp` - PR

d) `FieldState.getError()` - PR

e) Support binding `number | null` to - PR

f) `ngNoCva` opt-out for ControlValueAccessors - PR

m) ⚠️ `min` and `max` validation rules no longer accept strings - PR

b) `reportUploadProgress` & `reportDownloadProgress` replace `reportProgress` - commit 7c8c334

a) `withComponentInputBinding` options - PR

b) `browserUrl` input support for router links - PR

c) ⚠️ `provideRoutes()` removed - PR bdb6ae9

d) `unmatchedInputBehavior` option for `componentInputBinding` - PR

d) `provideWebMcpTools` — MCP integration for Angular apps - PR

e) `declareWebMcpTool` — the low-level imperative API - PR

a) ⚠️ `getAngularLib`/`setAngularLib` removed - PR

🛠️ CLI & Build Tooling (`angular/angular-cli`)

a) ⚡ Faster `ng add` with cached resolution - PR & PR

b) ⚠️ `process.env.PORT` takes priority in dev server - PR

c) `experimentalPlatform` renamed to `platform` - PR

d) ⚠️ `istanbul-lib-instrument` is now an optional peer dependency - PR