DEV Community: Rajat

@Service: Angular 22's @Service Decorator: Say Goodbye to @Injectable Boilerplate - Here’s What Changes (Part 4)

Rajat — Wed, 08 Jul 2026 13:30:00 +0000

A practical look at Angular's new, opinionated way to write services — what changed, why it matters, and when you should still reach for the old decorator

Quick question before we start: how many times have you typed @Injectable({ providedIn: 'root' }) this month without thinking twice about it?

If you've been writing Angular for more than a few weeks, the answer is probably "too many to count." It's one of those patterns we type on autopilot — copy, paste, rename the class, move on. Angular 22 finally does something about that muscle memory, and it's called @Service.

In this article we're going to unpack the new decorator like two developers pairing on a Friday afternoon: no fluff, just the "why," the "how," and the "when should I actually use this." By the end, you'll know:

Why the Angular team added @Service when @Injectable already worked fine
Exactly how @Service differs from @Injectable, with a side-by-side comparison
How to use the factory and autoProvided options for more advanced cases
How to write unit tests for services built with @Service
When you should skip @Service and stick with the classic decorator

Sound good? Follow along, and if you find this useful, consider following me here on Medium — I write about practical Angular and React patterns every week, not just "what's new" roundups.

Before we dive into the examples, a quick note: The code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular/React versions. Always refer to the official documentation for the most current API and syntax.

Why Angular introduced @Service

Let's start with the pattern we all know. Here's a completely typical Angular service, written the way we've written it for years:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable({ providedIn: 'root' })
export class UserService {
  constructor(private http: HttpClient) {}

  getUsers() {
    return this.http.get('/api/users');
  }
}

Nothing wrong with this. It works, it's familiar, and it's been the backbone of Angular DI since the framework's early days. But look closely at what's actually happening: @Injectable was built to describe how Angular should construct and provide a class, with support for useClass, useValue, useExisting, useFactory, non-root scopes, and constructor injection. Almost none of that flexibility gets used in a typical app service. Most of the time you just want a plain singleton that lives at the root of your app.

That mismatch — a powerful, general-purpose decorator being used for the simplest possible case — is exactly what @Service is designed to fix. It's a more opinionated decorator built around the assumption that you're creating a root-provided singleton and injecting your dependencies with the inject() function rather than a constructor.

Here's the same service, rewritten with @Service:

import { Service, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Service()
export class UserService {
  private http = inject(HttpClient);

  getUsers() {
    return this.http.get('/api/users');
  }
}

Same behavior, same singleton guarantees — Angular still gives you a single shared instance, automatic availability across the app, and tree-shakability if the service is never actually used. What's gone is the ceremony: no providedIn: 'root' to remember, no constructor parameter list to keep in sync every time a dependency changes.

Ever caught yourself forgetting providedIn: 'root' and wondering why you got a NullInjectorError at runtime? That's precisely the kind of small, avoidable mistake @Service removes from the equation, since root provisioning is now the default rather than something you opt into.

@Service vs @Injectable: what's actually different

It helps to see the two side by side instead of just reading about them. Here's how they compare:

Feature	`@Service`	`@Injectable`
`inject()` function support	Yes	Yes
Constructor-based DI	No	Yes
Root singleton by default	Yes	No — requires `providedIn: 'root'`
Advanced provider keys (`useClass`, `useValue`, etc.)	No	Yes
Custom initialization via factory	Yes, via `factory`	Yes, via `useFactory`
Non-root scopes (`platform`, etc.)	No	Yes

The biggest mental shift is that @Service only supports inject() for dependencies — there's no constructor injection at all. If your team has already standardized on inject() (which most modern Angular codebases have, especially since standalone components became the default), this isn't a big adjustment. If you're still writing constructor-based DI throughout your app, this is a good nudge to modernize.

Using a factory for conditional logic

Sometimes a service's implementation needs to change based on environment or configuration — think analytics that should be a no-op locally but forward events to a real tracker in production. @Service handles this with a single factory option that runs inside an injection context, so you can call inject() right inside it:

import { inject, InjectionToken, Service } from '@angular/core';

export const ANALYTICS_ENABLED = new InjectionToken<boolean>('ANALYTICS_ENABLED');

@Service({
  factory: () =>
    inject(ANALYTICS_ENABLED) ? new GoogleAnalytics() : new Analytics(),
})
export class Analytics {
  track(event: string, payload?: Record<string, unknown>) {
    // No-op by default.
  }
}

class GoogleAnalytics extends Analytics {
  override track(event: string, payload?: Record<string, unknown>) {
    // Sends the event to Google Analytics in production.
  }
}

The factory option is meant to replace useClass, useValue, useExisting, and useFactory from @Injectable. If your use case needs one of those specifically, that's your signal to reach for @Injectable instead — @Service is intentionally not trying to cover every advanced scenario.

Opting out of automatic root provisioning

Not every service should live at the root. If you want a service scoped to a specific route or component instead, set autoProvided: false and register it manually, the same way you would with @Injectable:

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

@Service({ autoProvided: false })
export class AnalyticsLogger {
  trackEvent(name: string) {
    console.log('event:', name);
  }
}

You'd then add AnalyticsLogger to the providers array of whichever component or route should own its lifecycle — nothing new here if you've scoped services before, just a slightly different starting point.

Using the service in a component

Injecting a @Service-decorated class works exactly the way you'd expect if you're already using inject():

import { Component, inject } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-user-list',
  template: `
    @if (users(); as list) {
      @for (user of list; track user.id) {
        <p>{{ user.name }}</p>
      }
    } @else {
      <p>Loading users...</p>
    }
  `,
})
export class UserList {
  private userService = inject(UserService);
  users = this.userService.getUsers();
}

Notice the @if / @for control flow syntax here instead of *ngIf / *ngFor — that's the modern Angular template syntax, and it pairs naturally with the rest of this more streamlined, signal-friendly style of writing components.

Writing unit tests for a @Service class

Good news: testing a @Service class is nearly identical to testing an @Injectable one, since TestBed doesn't care which decorator produced the provider — it just resolves the dependency graph. Here's a straightforward test for the UserService from earlier:

import { TestBed } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { UserService } from './user.service';

describe('UserService', () => {
  let service: UserService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
    });

    service = TestBed.inject(UserService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => {
    httpMock.verify();
  });

  it('should be created', () => {
    expect(service).toBeTruthy();
  });

  it('should fetch users from the API', () => {
    const mockUsers = [{ id: 1, name: 'Ada Lovelace' }];

    service.getUsers().subscribe((users) => {
      expect(users).toEqual(mockUsers);
    });

    const req = httpMock.expectOne('/api/users');
    expect(req.request.method).toBe('GET');
    req.flush(mockUsers);
  });
});

If you're testing a service created with autoProvided: false, just remember it won't be picked up automatically — you'll need to add it to the providers array of your TestBed.configureTestingModule call, the same way you would in a real component:

TestBed.configureTestingModule({
  providers: [AnalyticsLogger],
});

That's really the whole story for testing: the decorator changes how the service is provided, not how it behaves once it's resolved, so your existing testing habits carry over almost untouched.

What's your usual setup for mocking HTTP calls in service tests — HttpClientTestingModule, a hand-rolled spy, or something else? I'd genuinely like to know what's working for people right now.

Best practices for adopting @Service

A few things worth keeping in mind as you start using this in real projects:

Migrate incrementally. You don't need to convert every service in your app at once. @Service and @Injectable interoperate fine, so it's safe to introduce the new decorator only in new files and gradually touch old ones as you edit them anyway.
Pair it with inject() everywhere. Since @Service doesn't support constructor injection, standardizing on inject() across your whole codebase — components included — keeps things consistent and avoids a codebase with two competing DI styles.
Use factory sparingly. It's there for genuine conditional construction, not as a place to smuggle in business logic. If your factory function is getting long, that's usually a sign the logic belongs inside the class itself.
Reach for autoProvided: false deliberately. Scoping a service to a component is a real architectural decision — make sure it's intentional rather than a copy-pasted default.

When not to use @Service

@Service is not a full replacement for @Injectable, and that's fine — it was never meant to be. Stick with @Injectable when you need:

Constructor-based dependency injection, for example in a codebase that hasn't migrated to inject() yet
Advanced provider configuration such as useClass, useValue, or useExisting
A non-root scope like providedIn: 'platform'

If none of those apply, @Service is generally the more direct, more modern choice for a new singleton class.

Bonus tips

If you're using an editor with Angular language service support, decorator autocompletion for @Service should already suggest factory and autoProvided as you type — a quick way to double-check you're not misremembering the option names.
Consider adding an ESLint rule to your project that flags new @Injectable({ providedIn: 'root' }) usages without useClass/useFactory/etc., nudging your team toward @Service for the simple cases automatically.
When reviewing pull requests, a quick heuristic is: if the diff adds a constructor purely to inject one or two dependencies, that's often a good candidate to rewrite with inject() and @Service in the same pass.

Recap

@Service is Angular 22's answer to years of typing the same @Injectable({ providedIn: 'root' }) boilerplate for services that never needed the extra configuration in the first place. It defaults to a root-provided singleton, drops constructor injection in favor of inject(), and replaces the old provider keys with a single factory option for the cases that genuinely need one. It's not trying to replace @Injectable entirely — for constructor DI, advanced provider configuration, or non-root scopes, @Injectable is still the right tool. But for the everyday singleton service, which is most of them, @Service is a small change that removes a surprising amount of repetitive code.

Did this approach match how you've been writing services, or are you planning to hold off on adopting it for a while? Either way, I'd like to hear where you land.

What did you think?
Did this approach match how you are solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Meet injectAsync(): How injectAsync() in Angular 22 Can Shrink Your Initial Bundle Without Changing Your Architecture — Here's NG 22 (Part 3)

Rajat — Sat, 04 Jul 2026 12:15:36 +0000

Angular 22 quietly shipped one of the most developer-friendly DI improvements in years — and most people are still sleeping on it.

Have you ever injected a heavyweight service at the top of a component, knowing full well that 90% of your users will never actually trigger the feature that needs it? You import it, Angular boots it eagerly, it pulls in its own dependencies, and suddenly a chunk of your bundle is loaded just in case someone clicks "Export PDF." Sound familiar?

That exact pain point is what injectAsync() — one of the standout additions in Angular 22 — is designed to fix. And once you see how it works, you will start questioning every inject() call in your codebase.

In this article, you will learn:

What injectAsync() is and why it was introduced
How it differs from the familiar inject() function
Real-world use cases where lazy injection makes a meaningful difference
How to write unit tests for components that use it
Bonus tips to squeeze even more out of Angular 22's DI improvements

If this is the kind of deep-dive content you find useful, consider following me here on Medium — I publish one practical Angular article every week, and the Angular 22 series is just getting started.

Before we dive into the examples, a quick note: The code snippets provided here are meant purely for understanding the concept. Some syntax shown may reflect patterns from earlier Angular. Always refer to the official Angular documentation for the most current API and syntax.

What Changed in Angular 22's Dependency Injection

Angular 22 landed on June 3, 2026, and it came with a headline list that includes Signal Forms going stable, Resources graduating to production-ready, and OnPush becoming the default change detection strategy. Those are big deals. But tucked in alongside them is injectAsync() — a quieter addition that solves a very specific and very common problem.

To understand why it matters, you need to understand what eager injection actually costs you.

When you write inject(HeavyAnalyticsService) in a component, Angular resolves that dependency the moment the component is created. The service gets instantiated, its own dependencies get resolved, and everything that service depends on gets pulled into the initial load. If that service is only needed when a user clicks a specific button — maybe one that exports a report, or opens an advanced settings panel — you have just loaded that entire dependency graph on behalf of every user who lands on the page, even those who never click that button.

injectAsync() breaks that pattern. It lets you declare a dependency but defer its actual resolution until the moment you need it.

The Old Way: inject() and Its Limits

Here is what the traditional pattern looks like. You have a component with a button that triggers a PDF export. The PdfReportService is non-trivial — it pulls in a PDF generation library and potentially some charting utilities.

// pdf-report.service.ts
import { Service } from '@angular/core';

@Service()
export class PdfReportService {
  generate(data: ReportData): Promise<Blob> {
    // imagine this pulls in a large PDF library
    return heavyPdfLibrary.render(data);
  }
}

// dashboard.component.ts
import { Component, inject } from '@angular/core';
import { PdfReportService } from './pdf-report.service';

@Component({
  selector: 'app-dashboard',
  template: `
    <h1>Dashboard</h1>
    <button (click)="exportReport()">Export PDF</button>
  `
})
export class DashboardComponent {
  // This is resolved eagerly — the service is created when the component is created
  private readonly pdfService = inject(PdfReportService);

  exportReport() {
    this.pdfService.generate(this.getReportData());
  }
}

Every time DashboardComponent is created, PdfReportService is instantiated — regardless of whether the user ever touches that export button. In a large application, this adds up.

Introducing injectAsync(): Lazy DI on Demand

Angular 22 ships injectAsync() to solve exactly this. The function signature is simple: you pass it a factory function that returns a Promise resolving to the service instance. Angular handles the DI resolution for you, including respecting the injection context — you are not reaching outside the DI system.

Here is the same dashboard rewritten with injectAsync():

// dashboard.component.ts
import { Component, injectAsync } from '@angular/core';
import { PdfReportService } from './pdf-report.service';

@Component({
  selector: 'app-dashboard',
  template: `
    <h1>Dashboard</h1>
    <button (click)="exportReport()">Export PDF</button>
  `
})
export class DashboardComponent {
  // The service is NOT resolved until exportReport() is called
  private readonly getPdfService = injectAsync(() => import('./pdf-report.service')
    .then(m => m.PdfReportService));

  async exportReport() {
    const pdfService = await this.getPdfService();
    pdfService.generate(this.getReportData());
  }

  private getReportData(): ReportData {
    return { /* ... */ };
  }
}

What injectAsync() returns is not the service itself — it returns a function. Calling that function returns a Promise that resolves to the service. Angular ensures the instance is created within the correct injection context, so all the DI guarantees you expect still apply.

The key behavioral difference: the service (and its dependency graph) is only resolved the first time exportReport() is called. For users who never click that button, that chunk of code never loads.

How injectAsync() Works Under the Hood

You might be wondering: if injectAsync() returns a function that returns a Promise, how does Angular know to use DI for the resolved service?

The answer is that injectAsync() captures the injection context at the time it is called — which is during component construction, inside the injection context. The actual resolution is deferred, but the context reference is preserved. This is the same mechanism that allows things like toSignal() to work when called during component initialization.

This also means there is one important constraint: you must call injectAsync() during component construction (or in another valid injection context), not inside a method or lifecycle hook that runs later. The returned function can be called anywhere and at any time.

// CORRECT: called during construction
export class MyComponent {
  private readonly lazyService = injectAsync(() =>
    import('./heavy.service').then(m => m.HeavyService)
  );
}

// WRONG: called inside a method — will throw
export class MyComponent {
  someMethod() {
    // This will throw — no injection context here
    const lazyService = injectAsync(...);
  }
}

Real-World Use Cases

Let me walk through a few scenarios where injectAsync() earns its keep.

Use Case 1: Feature-Gated Admin Tools

Imagine a component that most users never interact with — say, a bulk data export panel visible only to admins. The export logic imports a heavy CSV serializer and a custom reporting engine.

// admin-panel.component.ts
import { Component, injectAsync, signal } from '@angular/core';

@Component({
  selector: 'app-admin-panel',
  template: `
    <section>
      <h2>Admin Tools</h2>
      @if (isExporting()) {
        <p role="status">Generating export...</p>
      }
      <button (click)="runExport()" [disabled]="isExporting()">
        Export All Records
      </button>
    </section>
  `
})
export class AdminPanelComponent {
  protected readonly isExporting = signal(false);

  private readonly getExportService = injectAsync(() =>
    import('../services/bulk-export.service').then(m => m.BulkExportService)
  );

  async runExport() {
    this.isExporting.set(true);
    try {
      const exportService = await this.getExportService();
      await exportService.run();
    } finally {
      this.isExporting.set(false);
    }
  }
}

For 95% of users who never visit the admin panel, the BulkExportService never loads.

Use Case 2: On-Demand Map Integration

A logistics dashboard shows a table of shipments by default, with an optional map view that loads a mapping SDK.

// shipment-tracker.component.ts
import { Component, injectAsync, signal } from '@angular/core';

@Component({
  selector: 'app-shipment-tracker',
  template: `
    <div class="toolbar">
      <button (click)="toggleView()">
        @if (showingMap()) { Show Table } @else { Show Map }
      </button>
    </div>

    @if (showingMap()) {
      <div id="map-container"></div>
    } @else {
      <app-shipment-table />
    }
  `
})
export class ShipmentTrackerComponent {
  protected readonly showingMap = signal(false);

  private readonly getMapService = injectAsync(() =>
    import('../services/map-renderer.service').then(m => m.MapRendererService)
  );

  async toggleView() {
    if (!this.showingMap()) {
      const mapService = await this.getMapService();
      mapService.initialize('map-container');
    }
    this.showingMap.update(v => !v);
  }
}

The mapping SDK and its associated bundle — which can be several hundred kilobytes — only loads the first time the user requests the map view.

Comparing inject() and injectAsync() Side by Side

Here is a direct comparison so the distinction stays clear:

Aspect	inject()	injectAsync()
Resolution timing	Eagerly at component creation	Lazily on first call
Return value	The service instance	A function returning Promise
Bundle impact	Included in initial bundle	Split into a lazy chunk
Usage context	Construction or injection context	Must be called in injection context; result usable anywhere
DI guarantees	Full	Full (context is captured)
Use when	Service always needed	Service conditionally needed

What pattern are you currently using for deferred feature loading in Angular? Drop a comment below — I am curious whether you have been reaching for lazy-loaded routes, dynamic imports, or something else entirely. This is exactly the kind of trade-off worth discussing.

Unit Testing Components That Use injectAsync()

Testing injectAsync() requires a slightly different approach than testing inject(). The key is that the lazy factory returns a Promise, so your tests need to handle async resolution.

First, let us look at the service we want to mock:

// bulk-export.service.ts
import { Service } from '@angular/core';

@Service()
export class BulkExportService {
  async run(): Promise<void> {
    // heavy export logic
  }
}

Now here is how to write a unit test for the AdminPanelComponent:

// admin-panel.component.spec.ts
import { ComponentFixture, TestBed, fakeAsync, tick } from '@angular/core/testing';
import { AdminPanelComponent } from './admin-panel.component';
import { BulkExportService } from '../services/bulk-export.service';

describe('AdminPanelComponent', () => {
  let fixture: ComponentFixture<AdminPanelComponent>;
  let component: AdminPanelComponent;
  let mockExportService: jasmine.SpyObj<BulkExportService>;

  beforeEach(async () => {
    mockExportService = jasmine.createSpyObj('BulkExportService', ['run']);
    mockExportService.run.and.returnValue(Promise.resolve());

    // Intercept the dynamic import by providing the service in the test module
    await TestBed.configureTestingModule({
      imports: [AdminPanelComponent],
      providers: [
        { provide: BulkExportService, useValue: mockExportService }
      ]
    }).compileComponents();

    fixture = TestBed.createComponent(AdminPanelComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create the component', () => {
    expect(component).toBeTruthy();
  });

  it('should show exporting state while export runs', fakeAsync(async () => {
    const exportPromise = component.runExport();
    fixture.detectChanges();

    // isExporting should be true during the async operation
    expect(component['isExporting']()).toBeTrue();

    await exportPromise;
    fixture.detectChanges();

    expect(component['isExporting']()).toBeFalse();
  }));

  it('should call BulkExportService.run() when export is triggered', async () => {
    await component.runExport();
    expect(mockExportService.run).toHaveBeenCalledTimes(1);
  });

  it('should reset isExporting to false even if export throws', async () => {
    mockExportService.run.and.returnValue(Promise.reject(new Error('Export failed')));

    try {
      await component.runExport();
    } catch {
      // expected
    }

    fixture.detectChanges();
    expect(component['isExporting']()).toBeFalse();
  });
});

A few things to note about this testing approach. Because injectAsync() captures the injection context at construction time and resolves through Angular's DI system, your TestBed.configureTestingModule providers are respected. You do not need to mock the dynamic import itself — providing the service in the test module is sufficient. The fakeAsync and async utilities both work here depending on the scenario.

injectAsync() and the New @Service Decorator

Angular 22 also ships the @Service() decorator, which is essentially a shorthand for @Injectable({ providedIn: 'root' }). One requirement of injectAsync() is that the lazily injected service must be auto-provided — either with @Service() or with @Injectable({ providedIn: 'root' }).

// analytics.service.ts
import { Service } from '@angular/core';

@Service()
export class AnalyticsService {
  trackEvent(name: string, data: Record<string, unknown>) {
    // heavy analytics logic
  }
}

If you try to use injectAsync() with a service that is provided only at the component level or module level, you will run into issues because the DI resolution path for lazy injection relies on the root injector. Keep this constraint in mind when designing services you intend to lazy-inject.

As noted in the Angular 22 release coverage from Ninja Squad, injectAsync() requires the service to be auto-provided, either with @Service() or with @Injectable({ providedIn: 'root' }).

Bundle Size: The Real Payoff

The most concrete benefit of injectAsync() is what it does to your initial bundle. When you use a regular dynamic import() inside a method, most bundlers (including esbuild and webpack) will create a separate chunk for that imported module. injectAsync() plugs directly into that same mechanism — the factory function you pass to it typically contains a dynamic import, which gives your bundler the signal it needs to split that code into a lazy chunk.

The practical result: code that was previously part of your main bundle (because the service was eagerly injected at the top of your component) now lives in a separate chunk that only downloads when the feature is actually used.

For a service backed by a large third-party library — a PDF engine, a charting library, a rich text editor — the savings can be measured in hundreds of kilobytes off your initial load.

Bonus Tips

Tip 1: Cache the resolved instance yourself if you want synchronous access later.

injectAsync() always returns a Promise, even on subsequent calls. If you need synchronous access after the first resolution, store the result in a signal or a class property.

private resolvedService: HeavyService | null = null;
private readonly getHeavyService = injectAsync(() =>
  import('./heavy.service').then(m => m.HeavyService)
);

async ensureService(): Promise<HeavyService> {
  if (!this.resolvedService) {
    this.resolvedService = await this.getHeavyService();
  }
  return this.resolvedService;
}

Tip 2: Combine with OnPush and Signals for maximum efficiency.

With OnPush now the default in Angular 22, components only re-render when their signal inputs change or when you explicitly trigger change detection. Pair injectAsync() with signals to communicate loading state, and your component will only repaint when it actually needs to.

Tip 3: Do not over-lazy-load.

injectAsync() is powerful but it is not a hammer for every nail. Services that are virtually always needed — routing, auth, core data — should stay as regular inject() calls. The overhead of a Promise resolution and a network request (for the lazy chunk) is only worth it when the service is genuinely conditional or infrequently needed.

Tip 4: Use TypeScript's type inference.

injectAsync() is fully typed. The returned function's return type is inferred from the factory's Promise type, so you get full autocomplete on the resolved service without any casting.

Tip 5: Watch the Angular 22 migration guide before upgrading.

Angular 22 introduces OnPush as the default, which means existing components without an explicit change detection strategy will behave differently after the upgrade. The ng update command automatically adds changeDetection: ChangeDetectionStrategy.Eager to components that do not specify a strategy, preserving their previous behavior during the upgrade. Run the migration before deploying.

Recap

Let us bring it all together. Angular 22's injectAsync() gives you a first-class, DI-aware way to defer service resolution until the moment you actually need it. Here is what we covered:

The problem: inject() resolves dependencies eagerly at component creation, pulling large services and their dependency graphs into the initial bundle even when they are only conditionally needed.
The solution: injectAsync() accepts a factory function (typically wrapping a dynamic import) and returns a function that, when called, resolves to the service via Angular's DI system.
The constraint: injectAsync() must be called during component construction (in an injection context), and the target service must be auto-provided via @Service() or @Injectable({ providedIn: 'root' }).
The payoff: Conditionally needed services are code-split into lazy chunks, reducing initial bundle size for features that only a subset of users ever trigger.
Testing: Providing the service in TestBed.configureTestingModule is sufficient — Angular's DI respects test providers even for lazy-injected services.

Angular 22 continues a pattern that the team has been building toward for several versions: a framework where every performance best practice is also the ergonomic default. injectAsync() fits that vision well.

What did you think?
Did this approach match how you are solving lazy loading in your Angular apps, or do you have a different take? Drop a comment — I genuinely read every single one. Specifically: are there services in your current codebase that you are already thinking about converting to injectAsync()?

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit** — Developer blog posts & tech discussions

Signal Forms Are Finally Production-Ready in Angular 22 — Here’s What Changes (Part 2)

Rajat — Wed, 24 Jun 2026 13:30:00 +0000

Angular 22 graduates Signal Forms from experimental to stable — here is everything you need to know to start using them today.

Part 1 of the series: The OnPush Default Has Arrived
Part 2 of the series: "Angular 22 Features Every Developer Should Know"

Have you ever looked at a Reactive Forms setup and thought, "this is way more code than the problem deserves"? You write a FormGroup, wire up FormControl objects, subscribe to valueChanges, manage your subscriptions, then manually trigger change detection just to show a validation error. For a login form. A login form.

If you have been working with Angular for any length of time, you know exactly what I am talking about.

Angular 22 — released on June 3, 2026 — changes that conversation entirely. Signal Forms have graduated from experimental to stable, and they are ready for production. In this article we will dig into what Signal Forms actually are, how they compare to Reactive Forms, and how to build something real with them.

By the end, you will know:

Why Signal Forms exist and what problem they solve
How form(), FormRoot, and FormField work
How to write validation, async validation, and debounced inputs
How to migrate gradually without rewriting your entire codebase
How to write unit tests for Signal Form components

If you enjoy this kind of deep-dive into Angular internals, follow me here on Medium. I publish one practical article every week, and I would love to have you along for the ride.

Note: The code snippets in this article reflect Angular 22 APIs as of the stable release. Some patterns shown may differ from earlier experimental versions of Signal Forms. Always refer to the official Angular documentation for the most current API and syntax.

Why Angular Needed Signal Forms

Let me show you something. Here is a minimal user registration form using Reactive Forms:

import { Component, OnDestroy, OnInit } from '@angular/core';
import {
  FormBuilder,
  FormGroup,
  Validators,
  ReactiveFormsModule
} from '@angular/forms';
import { Subject, takeUntil } from 'rxjs';

@Component({
  selector: 'app-registration',
  imports: [ReactiveFormsModule],
  template: `
    <form [formGroup]="form" (ngSubmit)="onSubmit()">
      <input formControlName="email" />
      @if (form.get('email')?.invalid && form.get('email')?.touched) {
        <span>Email is required</span>
      }
      <button type="submit">Register</button>
    </form>
  `
})
export class RegistrationComponent implements OnInit, OnDestroy {
  form!: FormGroup;
  private destroy$ = new Subject<void>();

  constructor(private fb: FormBuilder) {}

  ngOnInit(): void {
    this.form = this.fb.group({
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required, Validators.minLength(8)]]
    });

    this.form.get('email')!.valueChanges
      .pipe(takeUntil(this.destroy$))
      .subscribe(value => {
        // do something
      });
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }

  onSubmit(): void {
    if (this.form.valid) {
      console.log(this.form.value);
    }
  }
}

There is a lot going on here that has nothing to do with the actual form logic. You have lifecycle methods, manual subscription teardown with Subject, and imperative wiring between the FormBuilder and the template. Now multiply this across dozens of forms in a real application.

Reactive Forms were built in a different era of Angular — before Signals, before zoneless change detection, before the framework had a unified reactivity model. They work, but they carry the weight of that history. Every valueChanges subscription is a subscription that needs to be cleaned up. Every patchValue call is a push-based mutation that the rest of your Signal-based code has to accommodate.

Signal Forms were designed to fit naturally into the Signal ecosystem, with a model-driven API that is reactive by default and requires almost no boilerplate.

What Are Signal Forms?

At their core, Signal Forms replace the FormGroup/FormControl tree with a FieldTree — a deeply nested Signal structure where every property of your form model is represented as a Signal, complete with form state like dirty, invalid, touched, and errors.

The mental model shift is significant: instead of constructing a parallel form structure that mirrors your data model, you hand your data Signal directly to the form() function. Angular builds the FieldTree from it, and the template binds to that tree. There is no synchronization step, no patchValue, and no subscription to manage.

Here is the architecture at a glance:

Signal (your data)
       |
    form()
       |
    FieldTree (FieldRoot + FieldNode per property)
       |
  FormField directive (binds input -> FieldNode)
       |
   Template

Every node in the FieldTree is reactive. Reading field.value(), field.dirty(), or field.errors() in a template creates a reactive dependency — Angular will re-render only the parts of the template that actually consumed the changed signal.

Creating Your First Signal Form

Let us start with the simplest possible case: a contact form with a name and email.

import { Component, signal } from '@angular/core';
import { form, required } from '@angular/forms/signals';
import { FormField } from '@angular/forms/signals';

interface ContactModel {
  name: string;
  email: string;
}

@Component({
  selector: 'app-contact-form',
  imports: [FormField],
  template: `
    <form (submit)="onSubmit($event)">
      <div>
        <label for="name">Name</label>
        <input id="name" [formField]="contactForm.name" />
        @let nameField = contactForm.name();
        @if (nameField.touched() && nameField.invalid()) {
          <span class="error">Name is required</span>
        }
      </div>

      <div>
        <label for="email">Email</label>
        <input id="email" type="email" [formField]="contactForm.email" />
        @let emailField = contactForm.email();
        @if (emailField.touched() && emailField.invalid()) {
          <span class="error">Valid email is required</span>
        }
      </div>

      <button type="submit" [disabled]="contactForm().invalid()">Submit</button>
    </form>
  `
})
export class ContactFormComponent {
  protected readonly model = signal<ContactModel>({ name: '', email: '' });

  protected readonly contactForm = form(this.model, (f) => {
    required(f.name);
    required(f.email);
  });

  protected onSubmit(event: SubmitEvent): void {
    event.preventDefault();
    if (this.contactForm().valid()) {
      console.log(this.contactForm().value());
    }
  }
}

Notice what is not there. No FormBuilder. No ngOnInit. No this.form.get('email'). The form() function takes your Signal and an optional schema callback where you declare validation rules. What comes back is the FieldTree — and you bind directly to each node in the template using [formField].

FormRoot Explained

FormRoot is what form() returns at the top level. Think of it as the Signal Forms equivalent of FormGroup, but it is a Signal itself rather than a plain class instance.

Calling contactForm() — invoking it like a function — gives you access to the root-level form state:

// Check the whole form
const isFormValid = this.contactForm().valid();
const isFormDirty = this.contactForm().dirty();
const formValue = this.contactForm().value();

// Reset the entire form to its initial model value
this.contactForm().reset();

// Mark all fields as touched (useful before submit)
this.contactForm().markAllAsTouched();

One important behavior in Angular 22: markAsTouched() now marks a field and all its descendants as touched in one call. If you want to mark only the field itself without touching children, you pass { skipDescendants: true }.

FormField Explained

Each property in your FieldTree is a FormField — a Signal node that holds the field's current value and its form state. Reading any of these in a template creates a reactive dependency:

@Component({
  template: `
    <input [formField]="userForm.username" />

    @let username = userForm.username();
    @if (username.touched()) {
      @if (username.getError('required')) {
        <div class="error">Username is required</div>
      }
      @if (username.getError('minLength'); as minLengthError) {
        <div class="error">
          Username must be at least {{ minLengthError.minLength }} characters
        </div>
      }
    }
  `
})

The new getError() method in Angular 22 is a significant quality-of-life improvement. Previously, you had to iterate over field.errors() to find the specific error you wanted. Now you call getError('required') directly, and it narrows the return type for you — so TypeScript knows the shape of the minLength error object.

The key FormField state signals are:

field.value() — the current value
field.dirty() — true if the user has changed the value
field.touched() — true if the field has been blurred
field.invalid() — true if any validator is failing
field.errors() — the full error map
field.getError('key') — typed access to a specific error

Validation in Signal Forms

Built-in Validators

Angular 22's Signal Forms ship with a set of familiar validators, imported from @angular/forms/signals:

import {
  form,
  required,
  minLength,
  maxLength,
  pattern,
  email,
  min,
  max,
  minDate,
  maxDate
} from '@angular/forms/signals';

protected readonly profileForm = form(this.profile, (f) => {
  required(f.username);
  minLength(f.username, 3);
  maxLength(f.username, 30);
  pattern(f.username, /^[a-zA-Z0-9_]+$/);
  required(f.email);
  email(f.email);
  min(f.age, 18);
  max(f.age, 120);
  // Angular 22 new additions
  minDate(f.birthDate, new Date('1900-01-01'));
  maxDate(f.birthDate, new Date());
});

The minDate and maxDate validators are new in Angular 22 and add minDate/maxDate errors to the field's error map if the date value falls outside the specified range.

Custom Validators

Writing a custom validator is a plain function — no class, no AbstractControl:

import { FormFieldNode } from '@angular/forms/signals';

function noSpaces(field: FormFieldNode<string>): void {
  // Register a validator on this field
  field.addValidator({
    kind: 'noSpaces',
    validate: ({ valueOf }) => {
      const value = valueOf(field);
      return value.includes(' ')
        ? { noSpaces: { message: 'Value must not contain spaces' } }
        : null;
    }
  });
}

// Usage in form schema
protected readonly usernameForm = form(this.userModel, (f) => {
  required(f.username);
  noSpaces(f.username);
});

@if (usernameForm.username().getError('noSpaces'); as err) {
  <div class="error">{{ err.message }}</div>
}

The `when` Option

Angular 22 standardizes how conditional validators work. All validators and dynamic behaviors (disabled, readonly, hidden) now accept a when option:

protected readonly checkoutForm = form(this.order, (f) => {
  required(f.billingAddress);
  // Only validate shipping address when it differs from billing
  required(f.shippingAddress, {
    when: ({ valueOf }) => valueOf(f.useDifferentShipping)
  });
});

The old syntax of passing the reactive function as a direct argument still works but is now deprecated.

Async Validation

Async validation is where Signal Forms really shine compared to Reactive Forms. Rather than dealing with AsyncValidatorFn and Observable chains, you use validateHttp() to wire up an HTTP check declaratively:

import { form, required, validateHttp } from '@angular/forms/signals';

@Component({
  selector: 'app-register',
  imports: [FormField],
  template: `
    <input [formField]="registrationForm.email" type="email" />
    @let emailField = registrationForm.email();
    @if (emailField.isValidating()) {
      <span>Checking availability...</span>
    }
    @if (emailField.touched() && emailField.getError('emailTaken')) {
      <span class="error">This email is already registered</span>
    }
  `
})
export class RegisterComponent {
  protected readonly user = signal({ email: '', password: '' });

  protected readonly registrationForm = form(this.user, (f) => {
    required(f.email);
    validateHttp(f.email, {
      request: (email) => ({
        url: `/api/users/check-email`,
        params: { email: email.value() }
      }),
      error: 'emailTaken',
      debounce: 400
    });
  });
}

The debounce: 400 option tells Angular to wait 400 milliseconds after the last keystroke before sending the HTTP request. This replaces what used to require a custom debounceTime operator in an Observable pipe.

Debounce Support

Debouncing in Signal Forms comes in three flavors in Angular 22:

1. Debounce a field's value changes on input:

protected readonly searchForm = form(this.search, (f) => {
  debounce(f.query, 300);
});

2. Debounce only the async validators:

validateHttp(f.username, {
  request: (username) => `/api/users/check?username=${username.value()}`,
  error: 'usernameTaken',
  debounce: 500
});

3. Debounce a field's value changes on blur (new in Angular 22):

protected readonly form = form(this.model, (f) => {
  debounce(f.password, 'blur');
});

The 'blur' option is particularly useful for password fields and other inputs where you want to validate only after the user finishes typing and moves on — rather than on every keystroke.

Reactive Forms vs Signal Forms — A Direct Comparison

Aspect	Reactive Forms	Signal Forms
API surface	`FormGroup`, `FormControl`, `FormBuilder`	`form()`, `FieldTree`, `FormField`
RxJS dependency	Required (`valueChanges`, `statusChanges`)	None
Subscription management	Manual (`takeUntil`, `unsubscribe`)	Automatic
Change detection	Requires manual `markForCheck` in some cases	Fine-grained via Signals
Validation syntax	`Validators.required` in constructor	`required(f.field)` in schema
Async validation	`AsyncValidatorFn` with Observables	`validateHttp()` declaratively
Boilerplate	High	Low
Learning curve	Moderate (but familiar)	Low for Signal users
Template ergonomics	`form.get('field')?.invalid`	`formField().invalid()`
Debugging	Console logs, DevTools	Signal DevTools, typed errors
Scalability	Good	Excellent
Migration path	None needed	Gradual (compatible with CVA)

The biggest practical difference: with Reactive Forms, you are always managing two things — your data and your form state. With Signal Forms, there is only one source of truth: the Signal you handed to form(). The form state is derived from it, not a separate parallel construct.

What is the performance story here?

Worth pausing on this question, because "Signals are faster" is thrown around a lot without much substance.

With Reactive Forms under the Eager (formerly Default) change detection strategy, any event in the application — even one completely unrelated to your form — could trigger a re-check of the entire component tree. Angular 22 makes OnPush the default, which already helps. But inside an OnPush component, if you call markForCheck() to update form state, you mark the entire component for re-check — not just the template nodes that actually changed.

Signal Forms are different because each FormField is a Signal. When the email field's invalid() signal changes, Angular knows to update only the template expressions that read emailField.invalid(). Nothing else re-renders.

This becomes noticeable in large forms with many interdependent fields, or in forms that are part of complex component trees. Fine-grained updates are the answer to forms that feel sluggish as they scale.

This is a good moment to ask: are you currently migrating an existing Angular app to use Signals? Or are you starting fresh with Angular 22? Drop a comment below — the migration path is genuinely different depending on your starting point, and I am curious how teams are approaching it.

Migration Guidance

Should you migrate everything right now?

Short answer: no.

Reactive Forms are not going anywhere. They are stable, well-tested in production across millions of Angular applications, and will continue to be supported. There is no deprecation notice.

Signal Forms are the recommended path for new forms you are writing today. For existing forms, the migration calculus depends on a few things:

Forms with complex cross-field dependencies benefit the most — Signal Forms make these relationships explicit and reactive.
Large, heavily customized forms with many third-party ControlValueAccessor components may take longer, but Angular 22 makes this easier: ControlValueAccessor components are now compatible with formField, and any validation errors they define are propagated into the Signal Forms tree.
Utility-focused forms (admin tables, settings panels) where the form logic is simple and working fine — migrate these last, or not at all.

Hybrid Approach

The good news in Angular 22 is that FormValueControl — the new interface for custom form components — is now fully compatible with legacy Reactive Forms and Template-Driven Forms. This means you can migrate your custom components first, then migrate your forms progressively, without breaking the parts that are still using the old API.

Real-World Example: User Registration Form

Let us build something realistic — a registration form with validation, async email checking, debouncing, and a submit handler.

// registration.model.ts
export interface RegistrationModel {
  username: string;
  email: string;
  password: string;
  confirmPassword: string;
  birthDate: Date | null;
}

// registration.component.ts
import { Component, signal, computed } from '@angular/core';
import {
  form,
  required,
  minLength,
  maxLength,
  email,
  minDate,
  maxDate,
  debounce,
  validateHttp
} from '@angular/forms/signals';
import { FormField } from '@angular/forms/signals';
import { RegistrationModel } from './registration.model';

@Component({
  selector: 'app-registration',
  imports: [FormField],
  template: `
    <form (submit)="onSubmit($event)">

      <!-- Username -->
      <div class="field">
        <label for="username">Username</label>
        <input id="username" [formField]="registrationForm.username" />
        @let username = registrationForm.username();
        @if (username.touched()) {
          @if (username.getError('required')) {
            <p class="error">Username is required</p>
          }
          @if (username.getError('minLength'); as err) {
            <p class="error">At least {{ err.minLength }} characters</p>
          }
          @if (username.getError('maxLength'); as err) {
            <p class="error">No more than {{ err.maxLength }} characters</p>
          }
          @if (username.getError('usernameTaken')) {
            <p class="error">This username is already taken</p>
          }
          @if (username.isValidating()) {
            <p class="info">Checking availability...</p>
          }
        }
      </div>

      <!-- Email -->
      <div class="field">
        <label for="email">Email</label>
        <input id="email" type="email" [formField]="registrationForm.email" />
        @let emailField = registrationForm.email();
        @if (emailField.touched()) {
          @if (emailField.getError('required')) {
            <p class="error">Email is required</p>
          }
          @if (emailField.getError('email')) {
            <p class="error">Enter a valid email address</p>
          }
          @if (emailField.getError('emailTaken')) {
            <p class="error">An account with this email already exists</p>
          }
        }
      </div>

      <!-- Password -->
      <div class="field">
        <label for="password">Password</label>
        <input id="password" type="password" [formField]="registrationForm.password" />
        @let passwordField = registrationForm.password();
        @if (passwordField.touched() && passwordField.getError('minLength'); as err) {
          <p class="error">Password must be at least {{ err.minLength }} characters</p>
        }
      </div>

      <!-- Date of Birth -->
      <div class="field">
        <label for="birthDate">Date of Birth</label>
        <input id="birthDate" type="date" [formField]="registrationForm.birthDate" />
        @let birthField = registrationForm.birthDate();
        @if (birthField.touched()) {
          @if (birthField.getError('required')) {
            <p class="error">Date of birth is required</p>
          }
          @if (birthField.getError('maxDate')) {
            <p class="error">Date of birth cannot be in the future</p>
          }
          @if (birthField.getError('minDate')) {
            <p class="error">Please enter a valid date of birth</p>
          }
        }
      </div>

      <button
        type="submit"
        [disabled]="registrationForm().invalid() || registrationForm().isValidating()"
      >
        Create Account
      </button>

    </form>
  `
})
export class RegistrationComponent {
  private readonly initialModel: RegistrationModel = {
    username: '',
    email: '',
    password: '',
    confirmPassword: '',
    birthDate: null
  };

  protected readonly model = signal<RegistrationModel>(this.initialModel);

  protected readonly registrationForm = form(this.model, (f) => {
    // Username
    required(f.username);
    minLength(f.username, 3);
    maxLength(f.username, 20);
    validateHttp(f.username, {
      request: (field) => ({
        url: '/api/users/check-username',
        params: { username: field.value() }
      }),
      error: 'usernameTaken',
      debounce: 400
    });

    // Email
    required(f.email);
    email(f.email);
    validateHttp(f.email, {
      request: (field) => ({
        url: '/api/users/check-email',
        params: { email: field.value() }
      }),
      error: 'emailTaken',
      debounce: 400
    });

    // Password
    required(f.password);
    minLength(f.password, 8);
    // Debounce on blur for password
    debounce(f.password, 'blur');

    // Date of Birth
    required(f.birthDate);
    minDate(f.birthDate, new Date('1900-01-01'));
    maxDate(f.birthDate, new Date());
  });

  protected onSubmit(event: SubmitEvent): void {
    event.preventDefault();
    this.registrationForm().markAllAsTouched();

    if (this.registrationForm().valid() && !this.registrationForm().isValidating()) {
      const payload = this.registrationForm().value();
      console.log('Submitting:', payload);
      // call your registration service here
    }
  }
}

This is a complete, working registration form. No FormBuilder, no ngOnInit, no subscription cleanup. The async validators for username and email both debounce automatically to avoid a server request on every keystroke.

Unit Testing Signal Form Components

Testing Signal Form components is cleaner than testing Reactive Forms because there are fewer moving pieces to mock.

// registration.component.spec.ts
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { RegistrationComponent } from './registration.component';
import { HttpTestingController, provideHttpClientTesting } from '@angular/common/http/testing';
import { provideHttpClient } from '@angular/common/http';

describe('RegistrationComponent', () => {
  let fixture: ComponentFixture<RegistrationComponent>;
  let component: RegistrationComponent;
  let httpMock: HttpTestingController;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [RegistrationComponent],
      providers: [
        provideHttpClient(),
        provideHttpClientTesting()
      ]
    }).compileComponents();

    fixture = TestBed.createComponent(RegistrationComponent);
    component = fixture.componentInstance;
    httpMock = TestBed.inject(HttpTestingController);
    fixture.detectChanges();
  });

  afterEach(() => {
    httpMock.verify();
  });

  it('should create the component', () => {
    expect(component).toBeTruthy();
  });

  it('should mark username as invalid when empty and touched', () => {
    const usernameField = component['registrationForm'].username;
    // Mark as touched to trigger validation display
    usernameField().markAsTouched();
    fixture.detectChanges();

    expect(usernameField().invalid()).toBe(true);
    expect(usernameField().getError('required')).toBeTruthy();
  });

  it('should mark username as invalid when too short', () => {
    const form = component['registrationForm'];
    // Update the model to set the username
    component['model'].update(m => ({ ...m, username: 'ab' }));
    form.username().markAsTouched();
    fixture.detectChanges();

    expect(form.username().getError('minLength')).toBeTruthy();
    expect(form.username().getError('minLength')?.minLength).toBe(3);
  });

  it('should mark email as invalid for incorrect format', () => {
    component['model'].update(m => ({ ...m, email: 'not-an-email' }));
    component['registrationForm'].email().markAsTouched();
    fixture.detectChanges();

    expect(component['registrationForm'].email().getError('email')).toBeTruthy();
  });

  it('should show emailTaken error from async validator', async () => {
    component['model'].update(m => ({ ...m, email: 'existing@example.com' }));
    fixture.detectChanges();

    // Flush the debounce
    await new Promise(resolve => setTimeout(resolve, 500));
    fixture.detectChanges();

    const req = httpMock.expectOne(r => r.url.includes('/api/users/check-email'));
    req.flush({ taken: true }, { status: 200, statusText: 'OK' });
    fixture.detectChanges();

    expect(component['registrationForm'].email().getError('emailTaken')).toBeTruthy();
  });

  it('should not allow submit when form is invalid', () => {
    const submitSpy = jest.spyOn(console, 'log');
    const formElement = fixture.nativeElement.querySelector('form');
    formElement.dispatchEvent(new Event('submit'));
    fixture.detectChanges();

    expect(submitSpy).not.toHaveBeenCalledWith('Submitting:', expect.anything());
  });

  it('should mark all fields as touched on invalid submit', () => {
    const formElement = fixture.nativeElement.querySelector('form');
    formElement.dispatchEvent(new Event('submit'));
    fixture.detectChanges();

    const usernameField = component['registrationForm'].username();
    expect(usernameField.touched()).toBe(true);
  });
});

A few things to notice in these tests. First, you are testing the Signal directly — form.username().invalid() — which is synchronous and does not require a fake AbstractControl. Second, async validator tests use HttpTestingController the same way you would test an httpResource, which keeps the pattern consistent across your test suite.

Key Takeaways

Signal Forms in Angular 22 are not just a cosmetic improvement to Reactive Forms. They represent a fundamentally different model for thinking about form state — one that fits naturally alongside Signals, httpResource, and zoneless change detection.

The three things to take away from this article:

1. The data is the form. You hand a Signal to form() and Angular derives the form state from it. There is no parallel structure to synchronize.

2. Fine-grained reactivity means better performance. Only the template nodes that read a specific Signal re-render when that Signal changes. In large, complex forms this matters a lot.

3. Migration is gradual. Angular 22 ensures ControlValueAccessor and FormValueControl are mutually compatible, so you can migrate piece by piece without rewriting everything at once.

The right time to start using Signal Forms is on the next new form you write. That first one is the fastest way to develop an intuition for how they work.

Bonus Tips

Tip 1: Use linkedSignal for editable server data

When your form model comes from a server (loaded via httpResource), use linkedSignal to connect the resource value to a writable Signal that form() can consume:

protected readonly userResource = httpResource<User>(() => `/api/users/${this.userId()}`);

protected readonly editableUser = linkedSignal(() =>
  this.userResource.value() ?? { username: '', email: '' }
);

protected readonly userForm = form(this.editableUser, (f) => {
  required(f.username);
  required(f.email);
});

When the resource reloads, linkedSignal updates editableUser, which updates the form automatically.

Tip 2: Use reloadValidation() for retry logic

If an async validator fails due to a network error, you can retry it programmatically:

protected retryValidation(): void {
  this.registrationForm.email().reloadValidation();
}

This re-runs all async validators on the field and its descendants without requiring any user interaction.

Tip 3: The @Service decorator pairs well with Signal Forms

Angular 22 introduces the @Service() decorator as shorthand for @Injectable({ providedIn: 'root' }). Use it for services that your form components inject:

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

@Service()
export class UserValidationService {
  checkEmail(email: string) {
    // returns Observable or Promise
  }
}

Tip 4: Global debounced() is available for non-form use cases

Angular 22 also ships an experimental debounced() function that works on any Signal, not just form fields. Useful for search inputs that are not part of a form schema:

protected readonly query = signal('');
protected readonly debouncedQuery = debounced(() => this.query(), 300);
protected readonly results = httpResource(() => `/api/search?q=${this.debouncedQuery.value()}`);

Recap

Angular 22 Signal Forms are stable. Here is what we covered:

Reactive Forms carry significant boilerplate and rely on RxJS in ways that do not compose well with the Signal ecosystem
form() takes a Signal and returns a FieldTree — a deeply nested reactive structure where every property is a Signal with full form state
FormRoot manages top-level form state; FormField nodes manage per-field state with typed error access via getError()
Built-in validators like minDate and maxDate are new in Angular 22; the when option standardizes conditional validation
validateHttp() handles async validation declaratively, with built-in debounce support
The debounce(field, 'blur') option is new in Angular 22 for blur-triggered debouncing
Migration is gradual — ControlValueAccessor components work with Signal Forms out of the box
Testing follows the same pattern as testing other Signal-based code — synchronous and straightforward

What did you think?
Did your mental model of Angular forms shift after reading this, or do you see a case where Reactive Forms still have a clear advantage? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let us connect — find me on LinkedIn or GitHub and let us keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

The OnPush Default Has Arrived: A Practical Guide to Angular 22's Biggest Shift - Here's What Changes (Part 1)

Rajat — Wed, 17 Jun 2026 13:30:00 +0000

A practical, code-first tour of Angular 22's biggest change-detection shift — what breaks, what doesn't, and how to migrate without surprises*

Quick question before we get into it: when was the last time you added ChangeDetectionStrategy.OnPush to a component, ran the app, and then spent the next ten minutes wondering why a value on screen just... stopped updating?

If you've written Angular for more than a few months, that probably rings a bell. OnPush has always been the "fast lane" — fewer wasted checks, better performance — but it came with a tax. You had to opt in, understand exactly what triggers a re-render, and occasionally sprinkle markForCheck() around like seasoning when something didn't refresh the way you expected.

Angular 22 just changed that deal. As of this release, every component that doesn't explicitly set a change detection strategy now runs under OnPush automatically. The fast lane is now just... the lane.

This is part 1 of a series where we're going through Angular 22 feature by feature. This one is all about the change-detection shift specifically — what changed, why now, what can quietly break, and how to migrate without losing a weekend to it.

By the end, you'll know:

What actually changes when OnPush becomes the default — and what doesn't
Why ChangeDetectionStrategy.Default got renamed to Eager, and why that name makes more sense
The one scenario that can silently break your app after upgrading, with zero console errors
Why signals and OnPush are basically built for each other
Where this fits into Angular's bigger move toward zoneless apps
A step-by-step ng update walkthrough so you're not migrating blind

That's a lot of ground, but I promise it's more "oh, that makes sense" than "oh no." Let's get into it.

If you want the rest of this series as it drops — eleven more parts covering everything else in this release — following me here on Medium is the easiest way to not miss one.

Before we dive into the examples, a quick note: these snippets are meant purely for understanding the concepts in this release. Angular 22 only shipped on June 3, 2026, so a couple of the APIs we'll touch — especially the experimental debounced() helper — may still see small signature tweaks in patch releases. Always check the official Angular documentation for the exact, current syntax before shipping any of this to production.

OnPush Becomes the Default Change Detection Strategy

Let's start with the headline change.

Through Angular 21, if you wrote a component and didn't specify a changeDetection property, Angular used what was then called the Default strategy: on every change-detection cycle, it walked the entire component subtree and checked every binding — whether or not anything inside had actually changed. It worked, but in large component trees, it meant a lot of checks that found nothing to update.

As of Angular 22, that's flipped. Any @Component without an explicit changeDetection property now uses ChangeDetectionStrategy.OnPush automatically. No decorator property, no extra import, nothing to opt into.

Here's what that looks like in practice:

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

@Component({
  selector: 'app-counter',
  // No changeDetection property here -- this component is OnPush
  // automatically in Angular 22.
  template: `
    <button (click)="increment()">Count: {{ count() }}</button>
  `,
})
export class CounterComponent {
  readonly count = signal(0);

  increment() {
    this.count.update(c => c + 1);
  }
}

Nothing in that file mentions OnPush — and yet it behaves exactly like an OnPush component always has: Angular skips this subtree unless something inside explicitly says "something changed." Here, the signal read inside {{ count() }} and the (click) event binding both qualify, so the button updates correctly with zero extra ceremony.

If you've got a component that genuinely needs the old "check everything, every time" behavior — say, it wraps a third-party widget that mutates the DOM behind Angular's back — you can still opt into that explicitly:

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

@Component({
  selector: 'app-legacy-widget',
  changeDetection: ChangeDetectionStrategy.Eager, // restores pre-v22 default behavior
  template: `...`,
})
export class LegacyWidgetComponent {}

Which brings us to that name — Eager. Where did Default go?

ChangeDetectionStrategy.Default Is Now ChangeDetectionStrategy.Eager

This is a small change with a satisfying reason behind it.

ChangeDetectionStrategy.Default was deprecated in Angular 21.2 and replaced by ChangeDetectionStrategy.Eager in Angular 22. Both values represent exactly the behavior they always did — check the whole subtree, every time — but the new name describes what the strategy does, instead of describing its position in a list.

Think about it from the framework's point of view: once OnPush became the default, calling the other option "Default" stopped making sense. Default... compared to what? The Angular team's own discussion on this rename put it nicely: Default used to mean "run change detection on me by default," not "I am the default strategy" — and that mismatch was confusing enough to be worth fixing.

So now you have two clearly named strategies:

OnPush — skip this subtree unless something explicitly marks it dirty (the new default)
Eager — check this subtree on every CD run, no matter what (the old default, now opt-in)

If your codebase had components explicitly setting ChangeDetectionStrategy.Default, ng update rewrites them for you:

// Before Angular 22
@Component({
  selector: 'app-old',
  changeDetection: ChangeDetectionStrategy.Default,
  template: `...`,
})
export class OldComponent {}

// After ng update to Angular 22 -- same runtime behavior, new name
@Component({
  selector: 'app-old',
  changeDetection: ChangeDetectionStrategy.Eager,
  template: `...`,
})
export class OldComponent {}

Here's the side-by-side that I think makes this click fastest:

	`Eager` (formerly `Default`)	`OnPush` (now the default)
Default through...	Angular 21	Angular 22 onward
Subtree checked when	Every CD run, unconditionally	Only when something marks it dirty
What marks it dirty	Nothing needed — always checked	Signal reads in the template, `async` pipe emissions, event bindings, input changes, `markForCheck()`
Best fit	Legacy code mutating plain fields directly	Signal-based, zoneless-ready components

Once you see it laid out this way, the rename stops feeling cosmetic — it's Angular finally calling things what they actually are.

Now, here's the part I really want you to slow down for, because it's the one that can bite you with zero warning.

Quick gut check before we move on: have you ever upgraded a dependency and had some piece of UI just... stop updating, with nothing in the console to explain why? Hold that thought — the next section is exactly that scenario, and I'd genuinely like to know in the comments afterward whether it matches what you ran into.

Impact on Existing Apps: The Good News and the One Catch

Let's get the good news out of the way first.

When you run ng update to Angular 22, the migration:

Adds changeDetection: ChangeDetectionStrategy.Eager to every component decorator that doesn't already specify a strategy — preserving your exact pre-upgrade behavior.
Renames any existing ChangeDetectionStrategy.Default to ChangeDetectionStrategy.Eager.
Leaves any existing ChangeDetectionStrategy.OnPush alone.

In other words: your own application code keeps working exactly as it did the moment before you upgraded. Angular doesn't silently flip your components to OnPush behind your back — it explicitly tags them as Eager so nothing changes at runtime. That's the whole point of the migration.

So where's the catch?

ng update can only rewrite the source files inside your project. It has no way to touch code that's already compiled and sitting inside node_modules.

Picture a third-party library — say, a price-ticker widget — that ships a component with no explicit changeDetection, and updates its template by writing to a plain class property inside an RxJS subscription:

// A library component published before Angular 22.
// No explicit changeDetection -- pre-v22 this ran "check everything"
// and worked fine.
@Component({
  selector: 'price-ticker',
  // No changeDetection set here.
  template: `<span>Latest price: {{ price }}</span>`,
})
export class PriceTickerComponent implements OnInit {
  price = 0;

  constructor(private feed: PriceFeedService) {}

  ngOnInit() {
    this.feed.prices$.subscribe(p => {
      this.price = p; // plain field write -- Angular is never told to re-check
    });
  }
}

Before Angular 22, this worked because the component ran under Eager (then called Default) — Angular checked it on every cycle regardless. After you upgrade your app to Angular 22, that compiled library code still has no changeDetection property... which now means OnPush.

The result: the price stops updating on screen. No error. No console warning. No exception. The data is still arriving — prices$ is still emitting — but Angular was never told this component needs re-checking, so the template binding just freezes. If that same library does something imperative, like drawing onto a <canvas>, that keeps working fine. It's specifically Angular's template bindings — {{ }}, property bindings — that stop refreshing.

This is the single most important thing to test after upgrading: any third-party components that display live, push-based data.

If you hit this, you've got two options. The quick one, if you're still on zone.js:

export class PriceTickerComponent implements OnInit {
  price = 0;
  private cdr = inject(ChangeDetectorRef);

  constructor(private feed: PriceFeedService) {}

  ngOnInit() {
    this.feed.prices$.subscribe(p => {
      this.price = p;
      this.cdr.markForCheck(); // works with zone.js; does not help in zoneless apps
    });
  }
}

And the one that actually fixes it for good — bridge the observable into a signal:

import { Component, DestroyRef, inject } from '@angular/core';
import { takeUntilDestroyed, toSignal } from '@angular/core/rxjs-interop';

@Component({
  selector: 'price-ticker',
  template: `<span>Latest price: {{ price() }}</span>`,
})
export class PriceTickerComponent {
  private feed = inject(PriceFeedService);
  private destroyRef = inject(DestroyRef);

  readonly price = toSignal(
    this.feed.prices$.pipe(takeUntilDestroyed(this.destroyRef)),
    { initialValue: 0 },
  );
}

toSignal() turns the observable into a signal, and writing to a signal that's read in the template automatically marks the component dirty. This works correctly under Eager or OnPush, with zone.js or without it — which is really the whole theme of this release.

A handful of other breaking changes landed in the same v22 release, most of them auto-migrated:

strictTemplates is now true by default in tsconfig.json — the migration adds strictTemplates: false if you weren't using it, so your build doesn't suddenly fail on new type errors.
Optional chaining in templates now matches TypeScript semantics: project?.author returns undefined (not null) when the chain breaks. The migration wraps affected expressions in $safeNavigationMigration(...) so you can review them on your own schedule. On the upside, the compiler can now correctly narrow project?.author inside an @if (project?.author) guard, so a lot of those defensive ?. usages can eventually come out entirely.
HttpClient now defaults to the Fetch-based backend. withFetch() is deprecated and removed by the migration — or replaced with withXhr() if you relied on upload-progress events, which Fetch doesn't support.
provideClientHydration() now enables incremental hydration by default; the migration adds withNoIncrementalHydration() if you weren't previously opted in.
The canMatch guard signature gains a mandatory third parameter, currentSnapshot — auto-migrated. paramsInheritanceStrategy now defaults to 'always' — this one is not auto-migrated, so check your router config if your app relies on the old 'emptyOnly' behavior.
The toolchain floor moved up: TypeScript 6 is required (5.9 and below are unsupported), and Node 20 support is dropped (Node 22+ required, Node 26 officially supported).

None of these are scary individually, but they're exactly the kind of thing that's easy to skim past in a changelog and then debug three weeks later. Worth a slow read through your ng update diff.

Signals and OnPush: Why They Were Basically Built for Each Other

Here's the conceptual thread that ties this whole release together.

Signals tell Angular what changed. OnPush tells Angular what to skip. Put those together and you get a complete fine-grained reactivity model — and that's really why making OnPush the default "completes" the signals story rather than being some unrelated cleanup item.

Under the old Eager strategy, this distinction was invisible, because everything got checked regardless of whether a signal changed. Under OnPush, it's the entire mechanism: when a signal that's read in a template updates, Angular marks that component dirty and schedules a CD run. If nothing marks it dirty, the subtree is skipped entirely. The signal is the dirty flag.

This is also why the Resource API graduating to stable in Angular 22 matters so much for this topic. resource, rxResource, and httpResource all move from experimental to stable in this release, and httpResource in particular is a genuinely pleasant way to fetch data reactively:

import { Component, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';
import { CurrencyPipe } from '@angular/common';

interface Product {
  id: number;
  name: string;
  price: number;
}

@Component({
  selector: 'app-product-list',
  imports: [CurrencyPipe],
  template: `
    @if (productsResource.isLoading()) {
      <p>Loading products...</p>
    }
    @if (productsResource.error()) {
      <p>Something went wrong loading products.</p>
    } @else {
      @for (product of productsResource.value(); track product.id) {
        <div>{{ product.name }} -- {{ product.price | currency }}</div>
      }
    }
  `,
})
export class ProductListComponent {
  readonly category = signal('electronics');

  // Re-fetches automatically whenever category() changes.
  readonly productsResource = httpResource<Product[]>(
    () => `/api/products?category=${this.category()}`,
    { defaultValue: [] },
  );
}

Notice there's no changeDetection here either — it's OnPush by default, and it doesn't need to be anything else. productsResource.value(), .isLoading(), and .error() are all signals, so reading them in the template is exactly the "tell Angular what changed" signal that OnPush needs.

Angular 22 also adds an experimental debounced() helper, which is handy for search-as-you-type without hand-rolling RxJS debounceTime. One thing worth getting right here: debounced() takes a reactive function that reads a signal — not the signal itself — and it returns a Resource, not another signal:

import { Component, signal, debounced } from '@angular/core';
import { httpResource } from '@angular/common/http';

@Component({
  selector: 'app-search',
  template: `
    <input (input)="query.set($any($event.target).value)" placeholder="Search products..." />

    @if (debouncedQuery.isLoading()) {
      <p>Waiting for you to stop typing...</p>
    }

    @for (result of results.value(); track result.id) {
      <div>{{ result.name }}</div>
    }
  `,
})
export class SearchComponent {
  readonly query = signal('');

  // Settles 300ms after `query` stops changing.
  // Note: debounced() takes a function that reads the signal, not the signal itself.
  readonly debouncedQuery = debounced(() => this.query(), 300);

  readonly results = httpResource<{ id: number; name: string }[]>(
    () => `/api/search?q=${this.debouncedQuery.value()}`,
    { defaultValue: [] },
  );
}

While the user is typing, debouncedQuery.isLoading() is true, and debouncedQuery.value() still holds the last settled value — so your results don't flicker on every keystroke, and httpResource only re-fires once things have actually stabilized. Since debounced() is still experimental in v22, double-check its exact signature against whatever patch version you've got installed before shipping it.

The Zoneless Future: Where This Fits in the Bigger Picture

If you've been keeping half an eye on Angular over the last couple of years, this release probably doesn't feel like it came out of nowhere — and it shouldn't. Here's the timeline:

Angular 18 introduced zoneless change detection as an experimental preview, behind provideExperimentalZonelessChangeDetection.
Angular 19 refined the zoneless APIs and added SSR support.
Angular 20.2 promoted provideZonelessChangeDetection() to stable.
Angular 21 made zoneless the default for new applications — ng new no longer wires up zone.js or calls provideZonelessChangeDetection() explicitly; it's simply the baseline. Existing apps keep zone.js until they choose to remove it.
Angular 22 makes OnPush the default change detection strategy — the piece that makes zoneless apps performant by default, not just functional.

Put together: "check everything via zone.js" is no longer the starting point for any new Angular app. Signals tell Angular what changed, OnPush skips everything that wasn't touched, and zoneless removes the layer that used to trigger a check on every async operation.

That last part is the one that trips people up, so let's make it concrete. In a zone.js app, this used to "just work":

// Worked in zone.js apps because zone.js patches setTimeout
// and triggers a CD run when the callback fires.
@Component({
  selector: 'app-async-demo',
  template: `<p>{{ count }}</p>`,
})
export class AsyncDemoComponent {
  count = 0;

  ngOnInit() {
    setTimeout(() => {
      this.count++; // in a zoneless/OnPush app, the template silently won't update
    }, 1000);
  }
}

In a zoneless (or just plain OnPush) app, nothing tells Angular that count changed — setTimeout isn't patched, so there's no automatic CD trigger. The fix is the same one we used for the price ticker: make the state a signal.

@Component({
  selector: 'app-async-demo',
  template: `<p>{{ count() }}</p>`,
})
export class AsyncDemoComponent {
  count = signal(0);

  ngOnInit() {
    setTimeout(() => {
      this.count.update(c => c + 1); // marks the view dirty -- re-renders correctly
    }, 1000);
  }
}

And if you want to go fully zoneless explicitly — still entirely valid, just no longer something a brand-new project needs to add by hand:

import { bootstrapApplication } from '@angular/platform-browser';
import {
  provideZonelessChangeDetection,
  provideBrowserGlobalErrorListeners,
} from '@angular/core';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideZonelessChangeDetection(),
    provideBrowserGlobalErrorListeners(),
  ],
});

The rule of thumb going forward: change detection runs when a signal read in a template updates, the async pipe gets a new value, a template event fires, or something explicitly calls markForCheck() / ApplicationRef.tick(). Anything outside those four — a raw timer, a manual subscription writing to a plain field, a third-party library mutating data behind Angular's back — needs to be bridged into a signal to participate in rendering.

Migration Considerations: The ng update Walkthrough

Let's turn all of this into a checklist you can actually run through.

Step 1 — confirm your toolchain meets the new minimums:

node -v    # needs to be >= 22 (26 is supported)
npx tsc -v # needs to be >= 6.0

Step 2 — run the update. This applies every automatic migration we've covered: tagging unspecified components as Eager, renaming Default to Eager, the strictTemplates flag, the $safeNavigationMigration wrapper, the HTTP client changes, and the hydration flag.

ng update @angular/core@22 @angular/cli@22

Step 3 — build and run your full test suite. Most regressions from a change like this surface here, not in manual testing.

ng build
ng test

Step 4 — review what the migration actually touched, one concern at a time, instead of just accepting the diff:

grep -rn "ChangeDetectionStrategy.Eager" src/
grep -rn "\$safeNavigationMigration" src/
grep -rn "withNoIncrementalHydration\|withXhr" src/

That third command finds the optional-chaining wrappers and the HTTP/hydration flags — both things the migration added purely to preserve old behavior, and both good candidates to revisit once you've confirmed everything still works.

What ng update does not do for you:

It won't touch third-party node_modules packages — that's the "silent freeze" scenario from earlier. Your options are waiting for the library to update, wrapping its data source yourself with toSignal(), or pinning the dependency until you're ready to deal with it.
It won't change paramsInheritanceStrategy — if your app depends on the pre-v22 default, set it to 'emptyOnly' explicitly in your router config.
It won't convert your Eagertagged components to OnPush for you. That's a deliberate, per-component decision, and it usually starts with converting the component's state to signals.

That last point is worth walking through, because it's the actual "finish line" for each component. Here's one right after ng update — auto-migrated, behaving exactly as before:

// Right after ng update -- auto-generated, preserves old behavior.
@Component({
  selector: 'app-profile',
  changeDetection: ChangeDetectionStrategy.Eager,
  template: `<p>{{ user?.name }}</p>`,
})
export class ProfileComponent implements OnInit {
  user?: User;
  constructor(private userService: UserService) {}
  ngOnInit() {
    this.userService.getUser().subscribe(u => this.user = u);
  }
}

And here's the manual follow-up: convert the state to a signal, then delete the changeDetection line entirely.

import { Component, inject } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';

// Manual follow-up -- state is now a signal, no changeDetection override needed.
@Component({
  selector: 'app-profile',
  template: `<p>{{ user()?.name }}</p>`,
})
export class ProfileComponent {
  private userService = inject(UserService);
  readonly user = toSignal(this.userService.getUser());
}

No replacement annotation needed — OnPush is the default. That component is done.

Unit Testing OnPush and Signal-Based Components

A question I hear a lot when people first work with OnPush: "does this break my tests?" Mostly, no — but there's one habit worth building.

With TestBed, fixture.detectChanges() works exactly the same under OnPush as it always has when called manually — it forces a check regardless of whether the component thinks it's dirty. The difference only shows up when you're testing that an update happens automatically, without you calling detectChanges() yourself — which is precisely where signals help.

Here's a test for the CounterComponent from earlier:

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { CounterComponent } from './counter.component';

describe('CounterComponent', () => {
  let fixture: ComponentFixture<CounterComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CounterComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(CounterComponent);
    fixture.detectChanges();
  });

  it('renders the initial count', () => {
    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');
    expect(button.textContent).toContain('Count: 0');
  });

  it('updates the displayed count when the signal changes', () => {
    fixture.componentInstance.increment();
    fixture.detectChanges();

    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');
    expect(button.textContent).toContain('Count: 1');
  });

  it('updates the count via a real click event', () => {
    const button: HTMLButtonElement = fixture.nativeElement.querySelector('button');

    button.click();
    fixture.detectChanges();

    expect(button.textContent).toContain('Count: 1');
  });
});

A few things worth calling out:

We call fixture.detectChanges() after each state change — that's the test-environment equivalent of "Angular ran a CD cycle," and it's required regardless of strategy.
The third test fires a real DOM click, exercising the (click) event binding directly. This is the kind of test that used to quietly pass or quietly fail depending on which strategy a component happened to use — and now behaves consistently, because OnPush is the strategy either way.
If you're testing a component built around toSignal() and an observable (like our PriceTickerComponent), the same pattern applies: push a value through your mock service's subject, call fixture.detectChanges(), and assert on the rendered output. The signal write marks the view dirty; detectChanges() flushes it in the test.

If you're migrating your test setup to Vitest as part of this upgrade — Angular 22 continues investing here, including better fakeAsync support for teams making that move gradually — the same testing pattern applies. Only the runner and assertion syntax change, not the OnPush-related behavior itself.

Bonus Tips

A few smaller things that didn't need their own section but are worth keeping in your back pocket:

If a component "stops updating" after upgrading and you're not sure why, check whether it's coming from a third-party package first. The node_modules "silent freeze" is by far the most common surprise from this release.
You don't have to convert everything to signals on day one. Letting ng update mark your existing components as Eager and migrating component-by-component, on your own schedule, is exactly what the migration was designed to support.
Angular DevTools' signal graph is genuinely useful here, even if you're not pairing it with an AI agent — it's one of the fastest ways to see why a component did or didn't update.
When you do start converting components, prioritize the ones that already read from observables via async or manual subscriptions. Those are the most likely to have a "plain field write" hiding inside them, and toSignal() is almost always the cleanest fix.

Have you hit the "silent freeze" scenario yet, either during a test upgrade or in production? I'd genuinely love to know which library it was — drop it in the comments, it might save someone else a debugging session.

Recap

Here's the whole picture in one pass.

Angular 22 makes OnPush the default change detection strategy for any component that doesn't say otherwise. The old "check everything" behavior didn't disappear — it got renamed from Default to Eager, a name that actually describes what it does. ng update automatically tags your existing components as Eager so nothing changes at runtime on upgrade day, but it can't touch compiled code in node_modules — which is where the one real risk lives: third-party components with no explicit strategy and plain-field updates inside subscriptions can silently stop refreshing. The fix is always the same: bridge state into a signal with toSignal(), because a signal read in a template is exactly the "something changed" notification that OnPush — and zoneless apps — are built around. This release is also where the Resource API (resource, rxResource, httpResource) goes stable, and where the experimental debounced() helper shows up for search-as-you-type patterns.

If you take away one thing: go find the components that update via raw subscriptions or setTimeout, and start converting their state to signals. That single habit covers most of what this release changes for you.

What's your plan for rolling this out — run ng update and handle issues as they surface, or do a slower, component-by-component signal migration first? Tell me which one and why — I'm curious whether teams are converging on one approach.

What did you think?
Did this approach match how you're solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too — and if you've got a teammate who's about to upgrade to Angular 22, send this their way before they run into the silent-freeze surprise firsthand.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let's connect — find me on LinkedIn or GitHub and let's keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Mastering Angular Library Entry Points: Build Modular, Tree-Shakeable Packages Like a Pro

Rajat — Wed, 10 Jun 2026 13:30:00 +0000

How to create secondary entry points in Angular libraries for better modularity and smaller bundles

Ever wondered why @angular/common has both @angular/common and @angular/common/http? Or why some Angular libraries let you import specific features without dragging in the entire package? That's the magic of multiple entry points — and today, you're going to master this powerful pattern.

Picture this: You've built an amazing Angular library with utilities, components, and services. But when developers install it, they're forced to import everything, even if they only need one small feature. Their bundle size explodes, and suddenly your "helpful" library becomes a performance bottleneck. Sound familiar?

By the end of this article, you'll know exactly how to:

Structure Angular libraries with multiple entry points for optimal tree-shaking
Create secondary entry points that work seamlessly in both standard and Nx workspaces
Reduce bundle sizes by up to 70% through smart library architecture
Avoid the common pitfalls that plague multi-entry-point libraries

Let's dive in and transform your monolithic library into a lean, modular powerhouse.

What Are Entry Points in Angular Libraries?

Think of entry points as different doors into your library. Just like a building might have a main entrance, a side door, and a loading dock — each serving different purposes — your Angular library can expose multiple entry points for different features.

When you create a standard Angular library, you get one default entry point:

// Importing from main entry point
import { MyService } from '@mycompany/awesome-lib';

But with secondary entry points, you can offer more granular imports:

// Importing from secondary entry points
import { UtilityService } from '@mycompany/awesome-lib/utilities';
import { SharedComponent } from '@mycompany/awesome-lib/components';

The Angular team uses this pattern extensively. Take a look at Angular Material — you don't import the entire library; you cherry-pick what you need:

import { MatButtonModule } from '@angular/material/button';
import { MatDialogModule } from '@angular/material/dialog';

Quick question for you: Have you ever hesitated to add a library to your project because you were worried about bundle size? Drop a comment below — I'd love to hear your experience!

Why Multiple Entry Points Matter

Before we jump into implementation, let's talk about why you should care. Here's what multiple entry points bring to the table:

The Good Stuff

Surgical tree-shaking: Only the code that's actually imported makes it into the final bundle
Faster builds: Smaller compilation units mean quicker build times
Better organization: Logical separation of features makes your library more maintainable
Gradual adoption: Developers can use parts of your library without committing to the whole thing

The Trade-offs

More configuration: Each entry point needs its own setup
Versioning complexity: All entry points share the same version number
Publishing overhead: More moving parts means more things that can go wrong

Now that we're on the same page about the why, let's get our hands dirty with the how.

Step-by-Step: Creating Your First Secondary Entry Point

I'm going to walk you through creating a secondary entry point in a real Angular library. We'll build a library with a main entry point for core features and a secondary entry point for utilities.

Step 1: Generate Your Library

First, let's create a new Angular workspace and library:

ng new my-workspace --no-create-application
cd my-workspace
ng generate library @mycompany/awesome-lib

Your initial structure looks like this:

my-workspace/
├── projects/
│   └── mycompany/
│       └── awesome-lib/
│           ├── src/
│           │   ├── lib/
│           │   └── public-api.ts
│           ├── ng-package.json
│           └── package.json

Step 2: Create the Secondary Entry Point Folder

Navigate to your library folder and create a new directory for your secondary entry point:

cd projects/mycompany/awesome-lib
mkdir utilities

Step 3: Configure the Secondary Entry Point

Create a ng-package.json file inside the utilities folder:

// projects/mycompany/awesome-lib/utilities/ng-package.json
{
  "$schema": "../../../node_modules/ng-packagr/ng-package.schema.json",
  "lib": {
    "entryFile": "public-api.ts"
  }
}

Step 4: Set Up the Public API

Create the public API file for your utilities:

// projects/mycompany/awesome-lib/utilities/public-api.ts
export * from './src/string-utils';
export * from './src/date-utils';
export * from './src/array-utils';

Step 5: Create Your Utility Services

Let's add some actual utilities. Here's a string utility service:

// projects/mycompany/awesome-lib/utilities/src/string-utils.ts
import { Injectable } from '@angular/core';

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

  capitalize(text: string): string {
    if (!text) return '';
    return text.charAt(0).toUpperCase() + text.slice(1).toLowerCase();
  }

  truncate(text: string, maxLength: number, suffix = '...'): string {
    if (text.length <= maxLength) return text;
    return text.slice(0, maxLength - suffix.length) + suffix;
  }

  slugify(text: string): string {
    return text
      .toLowerCase()
      .trim()
      .replace(/[^\w\s-]/g, '')
      .replace(/[\s_-]+/g, '-')
      .replace(/^-+|-+$/g, '');
  }
}

And a date utility service:

// projects/mycompany/awesome-lib/utilities/src/date-utils.ts
import { Injectable } from '@angular/core';

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

  formatRelativeTime(date: Date): string {
    const now = new Date();
    const diffInSeconds = Math.floor((now.getTime() - date.getTime()) / 1000);

    if (diffInSeconds < 60) return 'just now';
    if (diffInSeconds < 3600) return `${Math.floor(diffInSeconds / 60)} minutes ago`;
    if (diffInSeconds < 86400) return `${Math.floor(diffInSeconds / 3600)} hours ago`;
    return `${Math.floor(diffInSeconds / 86400)} days ago`;
  }

  isWeekend(date: Date): boolean {
    const day = date.getDay();
    return day === 0 || day === 6;
  }

  addBusinessDays(date: Date, days: number): Date {
    const result = new Date(date);
    let daysAdded = 0;

    while (daysAdded < days) {
      result.setDate(result.getDate() + 1);
      if (!this.isWeekend(result)) {
        daysAdded++;
      }
    }

    return result;
  }
}

Step 6: Update Package.json Exports

Modern Angular uses the exports field in package.json to define entry points. Update your library's package.json:

// projects/mycompany/awesome-lib/package.json
{
  "name": "@mycompany/awesome-lib",
  "version": "1.0.0",
  "peerDependencies": {
    "@angular/common": "^18.0.0",
    "@angular/core": "^18.0.0"
  },
  "dependencies": {
    "tslib": "^2.3.0"
  },
  "exports": {
    ".": {
      "types": "./index.d.ts",
      "esm2022": "./esm2022/mycompany-awesome-lib.mjs",
      "esm": "./esm2022/mycompany-awesome-lib.mjs",
      "default": "./fesm2022/mycompany-awesome-lib.mjs"
    },
    "./utilities": {
      "types": "./utilities/index.d.ts",
      "esm2022": "./esm2022/utilities/mycompany-awesome-lib-utilities.mjs",
      "esm": "./esm2022/utilities/mycompany-awesome-lib-utilities.mjs",
      "default": "./fesm2022/mycompany-awesome-lib-utilities.mjs"
    }
  },
  "sideEffects": false
}

Step 7: Build and Verify

Build your library to ensure everything is configured correctly:

ng build @mycompany/awesome-lib

After building, check the dist folder. You should see separate bundles for each entry point:

dist/mycompany/awesome-lib/
├── fesm2022/
│   ├── mycompany-awesome-lib.mjs
│   └── mycompany-awesome-lib-utilities.mjs
├── utilities/
│   ├── index.d.ts
│   └── package.json
└── package.json

Implementing in an Nx Monorepo

Working with Nx? The process is slightly different but even more powerful. Nx provides generators that handle most of the boilerplate for you.

Generate a Library with Secondary Entry Points in Nx

npx nx generate @nx/angular:library my-lib --buildable --publishable --importPath=@mycompany/my-lib

# Add a secondary entry point
npx nx generate @nx/angular:library-secondary-entry-point --library=my-lib --name=utilities

Nx automatically configures the ng-package.json and updates your tsconfig paths. The structure looks like this:

libs/
└── my-lib/
    ├── src/
    │   ├── index.ts
    │   └── lib/
    ├── utilities/
    │   ├── src/
    │   │   ├── index.ts
    │   │   └── lib/
    │   └── ng-package.json
    └── ng-package.json

Here's a question for you: Are you using Nx in your projects? What's your favorite feature? Let me know in the comments!

Consuming Your Multi-Entry Point Library

Now for the fun part — using your shiny new library in an Angular application!

Install Your Library

If you've published to npm:

npm install @mycompany/awesome-lib

Or link locally for development:

npm link @mycompany/awesome-lib

Import from Different Entry Points

In your Angular components, you can now import from specific entry points:

// app.component.ts
import { Component, OnInit } from '@angular/core';
import { StringUtilsService } from '@mycompany/awesome-lib/utilities';
import { DateUtilsService } from '@mycompany/awesome-lib/utilities';

@Component({
  selector: 'app-root',
  template: `
    <div class="container">
      <h1>{{ title }}</h1>
      <p>Slugified: {{ slug }}</p>
      <p>Posted: {{ relativeTime }}</p>
    </div>
  `
})
export class AppComponent implements OnInit {
  title = 'Using Multiple Entry Points';
  slug = '';
  relativeTime = '';

  constructor(
    private stringUtils: StringUtilsService,
    private dateUtils: DateUtilsService
  ) {}

  ngOnInit() {
    this.slug = this.stringUtils.slugify(this.title);
    this.relativeTime = this.dateUtils.formatRelativeTime(
      new Date(Date.now() - 3600000)
    );
  }
}

The beauty here? If you only import from @mycompany/awesome-lib/utilities, the main library code never makes it into your bundle. Tree-shaking at its finest!

Writing Unit Tests for Your Library

Testing is crucial for library development. Let's add comprehensive tests for our utility services:

// string-utils.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { StringUtilsService } from './string-utils';

describe('StringUtilsService', () => {
  let service: StringUtilsService;

  beforeEach(() => {
    TestBed.configureTestingModule({});
    service = TestBed.inject(StringUtilsService);
  });

  it('should be created', () => {
    expect(service).toBeTruthy();
  });

  describe('capitalize', () => {
    it('should capitalize first letter and lowercase rest', () => {
      expect(service.capitalize('hello WORLD')).toBe('Hello world');
    });

    it('should handle empty strings', () => {
      expect(service.capitalize('')).toBe('');
    });

    it('should handle single character strings', () => {
      expect(service.capitalize('a')).toBe('A');
    });
  });

  describe('truncate', () => {
    it('should truncate long text', () => {
      const text = 'This is a very long text that needs truncation';
      expect(service.truncate(text, 20)).toBe('This is a very lo...');
    });

    it('should not truncate short text', () => {
      expect(service.truncate('Short', 10)).toBe('Short');
    });

    it('should use custom suffix', () => {
      expect(service.truncate('Long text here', 10, '→')).toBe('Long text→');
    });
  });

  describe('slugify', () => {
    it('should create URL-friendly slugs', () => {
      expect(service.slugify('Hello World!')).toBe('hello-world');
      expect(service.slugify('  Angular & TypeScript  ')).toBe('angular-typescript');
      expect(service.slugify('100% Awesome!!!')).toBe('100-awesome');
    });
  });
});

And for the date utilities:

// date-utils.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { DateUtilsService } from './date-utils';

describe('DateUtilsService', () => {
  let service: DateUtilsService;

  beforeEach(() => {
    TestBed.configureTestingModule({});
    service = TestBed.inject(DateUtilsService);
  });

  describe('formatRelativeTime', () => {
    it('should format recent times as "just now"', () => {
      const now = new Date();
      expect(service.formatRelativeTime(now)).toBe('just now');
    });

    it('should format minutes ago correctly', () => {
      const thirtyMinutesAgo = new Date(Date.now() - 30 * 60 * 1000);
      expect(service.formatRelativeTime(thirtyMinutesAgo)).toBe('30 minutes ago');
    });

    it('should format hours ago correctly', () => {
      const twoHoursAgo = new Date(Date.now() - 2 * 60 * 60 * 1000);
      expect(service.formatRelativeTime(twoHoursAgo)).toBe('2 hours ago');
    });
  });

  describe('isWeekend', () => {
    it('should identify weekends correctly', () => {
      const saturday = new Date('2024-01-06'); // Saturday
      const sunday = new Date('2024-01-07'); // Sunday
      const monday = new Date('2024-01-08'); // Monday

      expect(service.isWeekend(saturday)).toBe(true);
      expect(service.isWeekend(sunday)).toBe(true);
      expect(service.isWeekend(monday)).toBe(false);
    });
  });

  describe('addBusinessDays', () => {
    it('should skip weekends when adding business days', () => {
      const friday = new Date('2024-01-05'); // Friday
      const result = service.addBusinessDays(friday, 3);

      // Should be Wednesday (skipping Saturday and Sunday)
      expect(result.getDay()).toBe(3);
      expect(result.getDate()).toBe(10);
    });
  });
});

Run your tests with:

ng test @mycompany/awesome-lib

Troubleshooting Common Issues

Let's address the gotchas that trip up most developers:

Issue 1: "Cannot find module '@mycompany/awesome-lib/utilities'"

Solution: Check your package.json exports field. The path must match exactly:

"exports": {
  "./utilities": { ... }  // Note the "./" prefix
}

Issue 2: Build Fails with "Public API exports not found"

Solution: Ensure your public-api.ts file exists and exports are correct:

// Correct
export * from './src/my-service';

// Incorrect - missing 'src' folder
export * from './my-service';

Issue 3: TypeScript Can't Find Types

Solution: Update your tsconfig.json paths:

{
  "compilerOptions": {
    "paths": {
      "@mycompany/awesome-lib": ["dist/mycompany/awesome-lib"],
      "@mycompany/awesome-lib/*": ["dist/mycompany/awesome-lib/*"]
    }
  }
}

Issue 4: Entry Point Not Tree-Shaken

Solution: Add "sideEffects": false to your package.json. This tells bundlers that your code is side-effect free and safe to tree-shake.

Best Practices and When to Use Multiple Entry Points

Not every library needs multiple entry points. Here's my decision framework:

Use Multiple Entry Points When:

Your library has distinct, independent feature sets
Users typically only need a subset of your functionality
Bundle size is a critical concern for your users
You're building a utility library with many standalone functions

Keep a Single Entry Point When:

Your library is small (< 50KB)
All features are tightly coupled
Users typically need everything you provide
The added complexity isn't worth the marginal gains

Pro Tips from the Trenches

1. Group Related Features: Don't create an entry point for every single service. Group related functionality:

@mycompany/ui-kit/buttons
@mycompany/ui-kit/forms
@mycompany/ui-kit/layout

2. Version Everything Together: All entry points share the same version. Don't try to version them independently — it's a nightmare.

3. Document Import Paths: Make it crystal clear how to import from each entry point. Good documentation beats clever code every time.

4. Test Bundle Output: Use tools like webpack-bundle-analyzer to verify that tree-shaking actually works:

npm install -D webpack-bundle-analyzer
ng build --stats-json
npx webpack-bundle-analyzer dist/stats.json

Bonus Tip: Automating Entry Point Creation

Here's a quick Node.js script to generate new entry points automatically:

// scripts/create-entry-point.js
const fs = require('fs');
const path = require('path');

function createEntryPoint(name) {
  const libPath = 'projects/mycompany/awesome-lib';
  const entryPath = path.join(libPath, name);

  // Create directory
  fs.mkdirSync(entryPath, { recursive: true });
  fs.mkdirSync(path.join(entryPath, 'src'), { recursive: true });

  // Create ng-package.json
  const ngPackageContent = {
    "$schema": "../../../node_modules/ng-packagr/ng-package.schema.json",
    "lib": {
      "entryFile": "public-api.ts"
    }
  };

  fs.writeFileSync(
    path.join(entryPath, 'ng-package.json'),
    JSON.stringify(ngPackageContent, null, 2)
  );

  // Create public-api.ts
  fs.writeFileSync(
    path.join(entryPath, 'public-api.ts'),
    `// Public API Surface of ${name}\n`
  );

  console.log(`Entry point '${name}' created successfully!`);
}

// Usage: node scripts/create-entry-point.js my-feature
createEntryPoint(process.argv[2]);

Recap: Your Entry Point Mastery Checklist

Let's recap what you've learned today:

Entry points are doors into your library — each one provides access to specific features
Secondary entry points enable surgical imports — users only bundle what they actually use
Configuration is straightforward — ng-package.json, public-api.ts, and package.json exports
Testing is non-negotiable — comprehensive tests ensure your library works reliably
Not every library needs multiple entry points — use them when they solve real problems

You now have the knowledge to create professional-grade Angular libraries that respect your users' bundle sizes while maintaining clean architecture. The next time you build a library, you'll know exactly when and how to leverage multiple entry points.

What's Your Next Move?

What did you think? Have you struggled with large library bundles before? What approach are you most excited to try? Drop a comment below — I read every single one and often write follow-up articles based on your questions!

Found this helpful? If this article saved you from bundle bloat, hit that clap button! Seriously, every clap helps other developers discover these techniques. Go ahead, you can clap up to 50 times — I dare you to see how fast you can click!

Want more Angular deep dives? I publish practical Angular insights every week. Follow me here on Medium and never miss an article. Better yet, join my newsletter where I share exclusive tips and early access to new content before it goes public.

Your action items:

Audit your existing libraries — do any need splitting into entry points?
Try the techniques in this article on a real project
Share your results in the comments
Challenge a colleague to optimize their library architecture

Remember: great developers don't just write code that works — they write code that scales, performs, and respects their users' constraints. Now go forth and build something awesome!

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Optimize Angular Bundle Size in 4 Steps: From Bloated to Lightning-Fast

Rajat — Wed, 03 Jun 2026 13:30:00 +0000

Ship faster apps with smaller bundles — your users (and Lighthouse score) will thank you

Ever deployed an Angular app only to watch users bounce because it took forever to load? You're not alone. I've seen Angular apps balloon to 5MB+ bundles, crushing performance and killing user experience. But here's the thing — most of that weight is completely unnecessary.

What if I told you that you could slash your bundle size by 60% or more with just four strategic optimizations?

Before we dive into the examples, a quick note:
The code snippets provided here may be syntax from earlier Angular versions. Code Snippets just for understanding only.

By the end of this article, you'll know exactly how to analyze, optimize, and maintain lean Angular bundles that load in seconds, not minutes. We'll dive into practical techniques that you can implement today, complete with code examples that actually work in Angular 18+.

Why Bundle Size is Your Silent Performance Killer

Your Angular bundle size directly impacts:

Initial load time: Every 100KB adds roughly 1 second on 3G
SEO rankings: Google penalizes slow sites (Core Web Vitals matter!)
Conversion rates: Amazon found every 100ms delay costs 1% in sales

Angular's build system (now using ESBuild by default) does some optimization out of the box, but it's not magic. Without deliberate optimization, your bundles accumulate cruft faster than a developer's Downloads folder.

When Should You Start Optimizing?

Here's when bundle optimization becomes critical:

Your main bundle exceeds 500KB (gzipped)
Lighthouse Performance score drops below 70
Initial load takes more than 3 seconds on 4G
Users complain about sluggish performance
Your analytics show high bounce rates on first visit

Quick check: Run ng build and look at the output. See those yellow or red warnings about bundle sizes? Time to optimize.

Step 1: Analyze Your Bundle (Know Your Enemy)

You can't fix what you can't measure. Let's expose what's bloating your bundle.

# Install webpack-bundle-analyzer
npm install --save-dev webpack-bundle-analyzer

# Build with stats output
ng build --stats-json

# Analyze the bundle
npx webpack-bundle-analyzer dist/your-app/stats.json

For a more integrated approach, use source-map-explorer:

// package.json scripts
{
  "scripts": {
    "analyze": "ng build --source-map && source-map-explorer dist/**/*.js",
    "analyze:prod": "ng build --configuration production --source-map && source-map-explorer dist/**/*.js"
  }
}

// Install source-map-explorer
// npm install --save-dev source-map-explorer

// Run analysis
// npm run analyze:prod

This generates an interactive treemap showing exactly what's eating your bundle space. I bet you'll find surprises — like that one library you imported for a single function.

Pro tip: Set up bundle analysis in your CI/CD pipeline. Track bundle size over time and catch bloat before it ships.

Step 2: Remove Unused Code and Dependencies

Time to go on a diet. Most Angular apps carry dead weight from unused imports and bloated libraries.

Smart Imports Save Kilobytes

// BAD: Imports entire RxJS library (200KB+)
import * as rxjs from 'rxjs';
import { Observable } from 'rxjs';

// BAD: Imports all operators
import * as operators from 'rxjs/operators';

// GOOD: Tree-shakable imports (only what you need)
import { Observable, Subject, of } from 'rxjs';
import { debounceTime, distinctUntilChanged, switchMap } from 'rxjs/operators';

// BAD: Importing entire lodash (70KB+)
import _ from 'lodash';
const result = _.debounce(fn, 300);

// GOOD: Import specific functions (2KB)
import debounce from 'lodash-es/debounce';
const result = debounce(fn, 300);

// Even better: Use native alternatives when possible
// Instead of lodash's map, filter, reduce — use native Array methods

// Component example with optimized imports
import { Component, OnInit, signal, computed } from '@angular/core';
import { CommonModule } from '@angular/common';
import { FormControl, ReactiveFormsModule } from '@angular/forms';
import { debounceTime, distinctUntilChanged } from 'rxjs/operators';

@Component({
  selector: 'app-search',
  imports: [CommonModule, ReactiveFormsModule],
  template: `
    <input [formControl]="searchControl" placeholder="Search...">
    @if (isSearching()) {
      <div>Searching...</div>
    }
  `
})
export class SearchComponent implements OnInit {
  searchControl = new FormControl('');
  isSearching = signal(false);

  ngOnInit() {
    this.searchControl.valueChanges.pipe(
      debounceTime(300),
      distinctUntilChanged()
    ).subscribe(value => {
      this.performSearch(value);
    });
  }

  private performSearch(query: string | null) {
    this.isSearching.set(true);
    // Search logic here
  }
}

Audit and Remove Unused Dependencies

# Find unused dependencies
npx depcheck

# Check bundle impact of each dependency
npx bundle-phobia-cli moment
# Shows: moment@2.29.4 is 72.8KB minified, 232KB minified+gzipped

# Alternative: use date-fns instead of moment
npm uninstall moment
npm install date-fns
# date-fns is tree-shakable, moment isn't

# Remove unused Angular packages
npm uninstall @angular/animations  # If not using animations
npm uninstall @angular/forms        # If only using reactive forms

Ever checked how much moment.js adds to your bundle? Spoiler: it's huge. Switch to date-fns and save 200KB+ instantly.

Step 3: Implement Lazy Loading and Standalone Components

This is where the magic happens. Lazy loading splits your app into chunks that load on-demand.

Modern Route-Based Lazy Loading

// app.routes.ts - Modern Angular 18+ routing
import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: '',
    loadComponent: () => import('./home/home.component').then(m => m.HomeComponent)
  },
  {
    path: 'dashboard',
    // Lazy load entire feature with child routes
    loadChildren: () => import('./dashboard/dashboard.routes').then(m => m.DASHBOARD_ROUTES)
  },
  {
    path: 'admin',
    // Lazy load with guards
    loadComponent: () => import('./admin/admin.component').then(m => m.AdminComponent),
    canActivate: [() => import('./guards/auth.guard').then(m => m.canActivate())]
  },
  {
    path: 'products',
    // Preload this route for better UX
    loadChildren: () => import('./products/products.routes').then(m => m.PRODUCTS_ROUTES),
    data: { preload: true }
  }
];

// dashboard/dashboard.routes.ts
import { Routes } from '@angular/router';

export const DASHBOARD_ROUTES: Routes = [
  {
    path: '',
    loadComponent: () => import('./dashboard-layout.component').then(m => m.DashboardLayoutComponent),
    children: [
      {
        path: 'analytics',
        loadComponent: () => import('./analytics/analytics.component').then(m => m.AnalyticsComponent)
      },
      {
        path: 'reports',
        loadComponent: () => import('./reports/reports.component').then(m => m.ReportsComponent)
      }
    ]
  }
];

// dashboard-layout.component.ts
import { Component } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-dashboard-layout',
  imports: [RouterOutlet, CommonModule],
  template: `
    <div class="dashboard-container">
      <nav class="sidebar">
        <a routerLink="analytics">Analytics</a>
        <a routerLink="reports">Reports</a>
      </nav>
      <main class="content">
        <router-outlet />
      </main>
    </div>
  `
})
export class DashboardLayoutComponent {}

Smart Component Lazy Loading

// chart-container.component.ts
import { Component, ViewContainerRef, signal } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-chart-container',
  imports: [CommonModule],
  template: `
    <button (click)="loadChart()">Show Analytics Chart</button>

    @if (chartLoaded()) {
      <div #chartContainer></div>
    } @else if (isLoading()) {
      <div class="spinner">Loading chart...</div>
    }
  `
})
export class ChartContainerComponent {
  chartLoaded = signal(false);
  isLoading = signal(false);

  constructor(private viewContainerRef: ViewContainerRef) {}

  async loadChart() {
    this.isLoading.set(true);

    // Dynamically import heavy chart component
    const { ChartComponent } = await import('./chart/chart.component');

    // Create component instance
    const componentRef = this.viewContainerRef.createComponent(ChartComponent);

    // Pass data to the component
    componentRef.instance.data = this.getChartData();

    this.chartLoaded.set(true);
    this.isLoading.set(false);
  }

  private getChartData() {
    return {
      labels: ['Jan', 'Feb', 'Mar'],
      values: [100, 200, 150]
    };
  }
}

// Lazy load heavy libraries conditionally
@Component({
  selector: 'app-editor',
  imports: [CommonModule],
  template: `
    <button (click)="initializeEditor()">Open Editor</button>
    @if (editorReady()) {
      <div #editorContainer></div>
    }
  `
})
export class EditorComponent {
  editorReady = signal(false);
  private editor: any;

  async initializeEditor() {
    // Load Monaco Editor only when needed (saves 2MB+!)
    const monaco = await import('monaco-editor');

    this.editor = monaco.editor.create(
      document.getElementById('editorContainer')!,
      {
        value: 'console.log("Hello world");',
        language: 'typescript',
        theme: 'vs-dark'
      }
    );

    this.editorReady.set(true);
  }

  ngOnDestroy() {
    this.editor?.dispose();
  }
}

Not everything needs to be route-based. Heavy components can be lazy-loaded on demand:Think about it — why load a 2MB chart library if 80% of users never click on the analytics tab?

Step 4: Enable Advanced Build Optimizations

Time to squeeze every last byte out of your build with Angular's optimization arsenal.

// angular.json - Production optimization settings
{
  "projects": {
    "your-app": {
      "architect": {
        "build": {
          "configurations": {
            "production": {
              "optimization": {
                "scripts": true,
                "styles": {
                  "minify": true,
                  "inlineCritical": true
                },
                "fonts": {
                  "inline": true
                }
              },
              "outputHashing": "all",
              "sourceMap": false,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "500kb",
                  "maximumError": "1mb"
                },
                {
                  "type": "anyComponentStyle",
                  "maximumWarning": "2kb",
                  "maximumError": "4kb"
                }
              ],
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ]
            },
            "development": {
              "optimization": false,
              "sourceMap": true,
              "vendorChunk": true,
              "buildOptimizer": false
            }
          }
        },
        "serve": {
          "configurations": {
            "production": {
              "buildTarget": "your-app:build:production",
              "gzip": true,
              "brotli": true
            }
          }
        }
      }
    }
  }
}

Enable Compression and Modern Build Features

// server.ts - Express server with compression
import compression from 'compression';
import express from 'express';

const app = express();

// Enable gzip/brotli compression
app.use(compression({
  level: 9, // Maximum compression
  threshold: 0, // Compress everything
  filter: (req, res) => {
    // Don't compress responses with this request header
    if (req.headers['x-no-compression']) {
      return false;
    }
    // Fallback to standard filter
    return compression.filter(req, res);
  }
}));

// Serve static files with proper cache headers
app.use(express.static('dist', {
  maxAge: '1y',
  etag: false,
  setHeaders: (res, path) => {
    if (path.endsWith('.html')) {
      // Don't cache HTML files
      res.setHeader('Cache-Control', 'no-cache, no-store, must-revalidate');
    }
  }
}));

// Build script with compression (package.json)
{
  "scripts": {
    "build:prod": "ng build --configuration production && npm run compress",
    "compress": "gzip -k -9 dist/**/*.{js,css,html} && brotli-cli compress dist/**/*.{js,css,html}",
    "analyze:size": "npm run build:prod && ls -lah dist/**/*.{js,css}"
  }
}

// Preload strategy for better performance
// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideRouter, withPreloading, PreloadAllModules } from '@angular/router';
import { routes } from './app.routes';

// Custom preload strategy
class CustomPreloadStrategy implements PreloadingStrategy {
  preload(route: Route, load: () => Observable<any>): Observable<any> {
    // Preload routes marked with data: { preload: true }
    return route.data && route.data['preload'] ? load() : of(null);
  }
}

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withPreloading(CustomPreloadStrategy)
    )
  ]
};

Testing Your Optimizations

Let's make sure our optimizations actually work:

// bundle-size.spec.ts - Unit test for bundle size
import { readFileSync, statSync } from 'fs';
import { join } from 'path';

describe('Bundle Size Tests', () => {
  const distPath = join(__dirname, '../../../dist');

  it('should keep main bundle under 500KB', () => {
    const mainBundle = join(distPath, 'main.js');
    const stats = statSync(mainBundle);
    const sizeInKB = stats.size / 1024;

    expect(sizeInKB).toBeLessThan(500);
  });

  it('should have lazy-loaded chunks', () => {
    const files = readdirSync(distPath);
    const lazyChunks = files.filter(f => f.includes('chunk'));

    expect(lazyChunks.length).toBeGreaterThan(0);
  });

  it('should not include unused libraries', () => {
    const mainContent = readFileSync(join(distPath, 'main.js'), 'utf-8');

    // Check that moment.js is not in the bundle
    expect(mainContent).not.toContain('moment');

    // Check that only used RxJS operators are included
    expect(mainContent).toContain('debounceTime');
    expect(mainContent).not.toContain('exhaustMap'); // Unused operator
  });
});

// performance.spec.ts - E2E performance tests
import { test, expect } from '@playwright/test';

test.describe('Performance Metrics', () => {
  test('should load within 3 seconds on slow 3G', async ({ page }) => {
    // Simulate slow 3G
    await page.route('**/*', route => route.continue());
    await page.context().setOffline(false);

    const client = await page.context().newCDPSession(page);
    await client.send('Network.emulateNetworkConditions', {
      offline: false,
      downloadThroughput: (1.6 * 1024 * 1024) / 8, // 1.6 Mbps
      uploadThroughput: (750 * 1024) / 8, // 750 Kbps
      latency: 150
    });

    const startTime = Date.now();
    await page.goto('http://localhost:4200');
    await page.waitForLoadState('networkidle');
    const loadTime = Date.now() - startTime;

    expect(loadTime).toBeLessThan(3000);
  });

  test('should have good Core Web Vitals', async ({ page }) => {
    await page.goto('http://localhost:4200');

    // Measure LCP (Largest Contentful Paint)
    const lcp = await page.evaluate(() => {
      return new Promise(resolve => {
        new PerformanceObserver(list => {
          const entries = list.getEntries();
          const lastEntry = entries[entries.length - 1];
          resolve(lastEntry.renderTime || lastEntry.loadTime);
        }).observe({ entryTypes: ['largest-contentful-paint'] });
      });
    });

    expect(lcp).toBeLessThan(2500); // Good LCP is under 2.5s
  });
});

Pros and Cons of Bundle Optimization

The Good Stuff:

50-70% faster initial load times — Users see content quicker
Better SEO rankings — Google loves fast sites
Lower bounce rates — Users stick around when apps load fast
Reduced hosting costs — Smaller files = less bandwidth
Improved mobile experience — Critical for users on slower connections

The Trade-offs:

More complex build configuration — Takes time to set up properly
Potential lazy-loading delays — Some features load on-demand
Debugging gets harder — Source maps disabled in production
Risk of over-optimization — Too many chunks can hurt performance
Maintenance overhead — Need to monitor bundle size regularly

How to Measure Your Success

Before celebrating, let's verify the improvements:

#!/bin/bash
# performance-check.sh

echo "Building optimized version..."
ng build --configuration production

echo "Bundle Size Analysis:"
echo "========================"

# Check main bundle size
MAIN_SIZE=$(stat -f%z dist/main.*.js 2>/dev/null || stat -c%s dist/main.*.js 2>/dev/null)
MAIN_SIZE_KB=$((MAIN_SIZE / 1024))

if [ $MAIN_SIZE_KB -lt 500 ]; then
  echo "Main bundle: ${MAIN_SIZE_KB}KB (Good!)"
else
  echo "Main bundle: ${MAIN_SIZE_KB}KB (Too large!)"
fi

# Check total size
TOTAL_SIZE=$(du -sh dist | cut -f1)
echo "Total dist size: $TOTAL_SIZE"

# Run Lighthouse
echo "Running Lighthouse..."
npx lighthouse http://localhost:4200 \
  --only-categories=performance \
  --output=json \
  --output-path=./lighthouse-report.json

# Parse and display score
PERF_SCORE=$(cat lighthouse-report.json | grep -o '"performance":{"score":[0-9.]*' | grep -o '[0-9.]*$')
SCORE_PERCENT=$(echo "$PERF_SCORE * 100" | bc)

echo "Lighthouse Performance Score: ${SCORE_PERCENT}%"

if (( $(echo "$PERF_SCORE >= 0.9" | bc -l) )); then
  echo "Excellent performance!"
elif (( $(echo "$PERF_SCORE >= 0.7" | bc -l) )); then
  echo "Good, but room for improvement"
else
  echo "Performance needs work"
fi

Real-world targets you should aim for:

Main bundle: Under 250KB (gzipped)
Lazy chunks: 50-150KB each
Total initial load: Under 500KB
Lighthouse score: 90+ for performance
First Contentful Paint: Under 1.5s
Time to Interactive: Under 3s

Common Mistakes to Avoid

Learn from my pain — here are the gotchas that waste hours:

1. Accidentally disabling tree-shaking:
Setting "sideEffects": false in the wrong package.json can break your app.

2. Forgetting to update budgets:
Your CI/CD should fail if bundles exceed limits. Don't let bloat sneak in.

3. Over-eager lazy loading:
Loading 50 tiny chunks is worse than one slightly larger bundle. Find the balance.

4. Loading unnecessary polyfills:
Angular 18 targets modern browsers by default. Don't ship IE11 polyfills in 2025!

5. Keeping source maps in production:
They're great for debugging but add 3-5x to your bundle size.

Bonus Tips from the Trenches

Here's what I wish someone told me earlier:

Use the Angular DevTools Profiler — It shows exactly which components are slowing down your app. Install the browser extension and look for components taking more than 16ms to render.

Consider Module Federation for micro-frontends — If your app is huge, split it into separate deployable units. Each team can optimize independently.

Preconnect to critical domains:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://api.yourapp.com">

Use a CDN for static assets — Your 500KB vendor bundle loads way faster from a CDN edge server than your origin.

Monitor bundle size in PR checks — Add this to your CI pipeline and reject PRs that increase bundle size without justification.

Quick Recap

You've just learned how to transform your bloated Angular app into a lean, mean, loading machine:

Analyze — Use webpack-bundle-analyzer to see what's eating space
Remove — Eliminate unused code and optimize imports
Split — Implement lazy loading for routes and heavy components
Optimize — Enable production builds with compression and budgets

The best part? These techniques compound. Combine all four and watch your bundle shrink by 60-80%.

Remember: Performance optimization isn't a one-time task. Make it part of your development workflow. Set up monitoring, enforce budgets, and regularly audit your dependencies.

Your users are waiting. Every second counts. Now go optimize that bundle!

What's Your Experience?

Have you tackled a massive Angular bundle before? What was your biggest surprise when you analyzed it? Drop a comment below — I'm curious what monsters you've found lurking in your bundles.

Found this helpful? Hit that button (you can clap up to 50 times, just saying) so other devs can discover these optimization techniques too.

Want more Angular performance tips delivered to your inbox? Follow me here on Medium or subscribe to my weekly newsletter where I share one actionable performance tip every Tuesday.

Action point: Pick ONE optimization from this article and implement it today. Then share your before/after bundle sizes in the comments. Let's see who gets the biggest reduction!

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Angular's Injection Context: The Hidden Runtime Environment Every Developer Should Master

Rajat — Wed, 27 May 2026 13:30:00 +0000

Understanding When and Where Angular's Dependency Injection Actually Works

If you have ever encountered the NG0203 error — inject() must be called from an injection context — and spent time wondering why a perfectly valid service injection works in one place but fails in another, this article explains exactly why.

Angular's dependency injection does not work everywhere. It requires a specific runtime environment called the Injection Context. Once you understand what that is, where it exists, and how to create it manually, you will stop guessing and start writing predictable, testable Angular code.

Before we dive into the examples, a quick note:
The code snippets provided here may be syntax from earlier Angular versions. Code Snippets just for understanding only.

This article covers:

What Injection Context is and why it matters
Every location where it exists in an Angular application
How to use runInInjectionContext and assertInInjectionContext
Modern DI patterns with signals and standalone components
Unit testing code that depends on injection context

What Is Dependency Injection Context?

Injection Context is the execution environment where Angular's DI system is active. It is the runtime state in which an injector is available, the inject() function can resolve tokens, and Angular understands the component or service hierarchy you are operating within.

Without it, inject() has no injector to consult and throws NG0203.

// Works — field initializer inside a component class
@Component({
  selector: 'app-user',
  template: `...`,
  standalone: true
})
export class UserComponent {
  private userService = inject(UserService); // Injection context is active here
}

// Fails — standalone function with no injector
function randomFunction() {
  const service = inject(SomeService); // Error NG0203
}

Where Injection Context Exists

Injection context is not magic — it exists in specific, predictable places.

1. Class Constructors

Any class instantiated by Angular's DI system has injection context in its constructor. Both inject() and constructor parameter injection work here.

@Injectable({ providedIn: 'root' })
export class DataService {
  private http = inject(HttpClient);

  constructor() {
    // Injection context is active inside constructors of DI-managed classes
    const logger = inject(LoggerService);
  }
}

@Component({
  selector: 'app-dashboard',
  template: `
    @if (data()) {
      <div>{{ data() }}</div>
    }
  `,
  standalone: true
})
export class DashboardComponent {
  private dataService = inject(DataService);

  constructor() {
    // Also valid here
  }
}

2. Field Initializers

Field initializers on Angular-managed classes run during construction, so injection context is active. This is the modern, preferred style — no constructor boilerplate required.

@Component({
  selector: 'app-profile',
  template: `
    @for (user of users(); track user.id) {
      <user-card [user]="user" />
    }
  `,
  standalone: true,
  imports: [UserCardComponent]
})
export class ProfileComponent {
  private userService = inject(UserService);
  private destroyRef = inject(DestroyRef);

  users = signal<User[]>([]);

  ngOnInit() {
    this.userService.getUsers()
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(users => this.users.set(users));
  }
}

3. Factory Functions in Providers

Factory functions used in provider definitions — including InjectionToken factories — run inside injection context. You can call inject() freely within them.

export const API_CONFIG = new InjectionToken<ApiConfig>('API_CONFIG', {
  providedIn: 'root',
  factory: () => {
    // Injection context is active inside factory functions
    const env = inject(EnvironmentService);

    return {
      baseUrl: env.apiUrl,
      timeout: 5000
    };
  }
});

@Component({
  selector: 'app-api-consumer',
  template: `...`,
  standalone: true
})
export class ApiConsumerComponent {
  private config = inject(API_CONFIG);
}

4. Functional Guards and Resolvers

Angular's functional guard and resolver APIs (CanActivateFn, ResolveFn, etc.) run inside injection context, so you can call inject() directly inside them.

export const authGuard: CanActivateFn = (route, state) => {
  const authService = inject(AuthService);
  const router = inject(Router);

  if (authService.isAuthenticated()) {
    return true;
  }

  return router.createUrlTree(['/login'], {
    queryParams: { returnUrl: state.url }
  });
};

export const routes: Routes = [
  {
    path: 'admin',
    loadComponent: () => import('./admin/admin.component'),
    canActivate: [authGuard]
  }
];

A resolver follows the same pattern:

export const userResolver: ResolveFn<User> = (route) => {
  const userService = inject(UserService);
  const userId = route.params['id'];

  return userService.getUser(userId);
};

@Component({
  selector: 'app-user-detail',
  template: `
    @if (user()) {
      <h1>{{ user()!.name }}</h1>
    }
  `,
  standalone: true
})
export class UserDetailComponent {
  private route = inject(ActivatedRoute);

  user = toSignal(
    this.route.data.pipe(map(data => data['user'] as User))
  );
}

Running Code in Injection Context: `runInInjectionContext`

Sometimes you need to call inject() from a place where injection context does not naturally exist — for example, inside a utility function called from a component method. runInInjectionContext solves this by manually establishing the context.

The Problem

// This fails — no injection context in a standalone utility function
export function logUserAction(action: string) {
  const logger = inject(LoggerService); // Error NG0203
  logger.log(`User action: ${action}`);
}

The Solution

@Component({
  selector: 'app-activity',
  template: `
    <button (click)="trackAction('clicked')">Track</button>
  `,
  standalone: true
})
export class ActivityComponent {
  private injector = inject(EnvironmentInjector);

  trackAction(action: string) {
    runInInjectionContext(this.injector, () => {
      logUserAction(action); // Now injection context is active
    });
  }
}

export function logUserAction(action: string) {
  const logger = inject(LoggerService);
  const userService = inject(UserService);

  logger.log({
    action,
    userId: userService.currentUser?.id,
    timestamp: Date.now()
  });
}

The key is injecting EnvironmentInjector (not Injector) when you need to pass it to runInInjectionContext, since that function requires an EnvironmentInjector or Injector instance.

Real-World Use: Service Method with Dynamic Injection

@Injectable({ providedIn: 'root' })
export class ApiService {
  private injector = inject(EnvironmentInjector);
  private http = inject(HttpClient);

  makeAuthenticatedRequest<T>(url: string): Observable<T> {
    return runInInjectionContext(this.injector, () => {
      const auth = inject(AuthService);
      const token = auth.getToken();

      return this.http.get<T>(url, {
        headers: { Authorization: `Bearer ${token}` }
      });
    });
  }
}

Note: in most cases it is cleaner to inject AuthService as a field. runInInjectionContext is best reserved for utilities and helpers that must remain decoupled from a specific class.

Writing Defensive Code: `assertInInjectionContext`

If you are writing a utility function that relies on injection context, you should call assertInInjectionContext at the top. This produces a clear, informative error immediately if the function is called in the wrong place, rather than a cryptic failure later.

export function createSignalFromObservable<T>(
  observableFactory: () => Observable<T>
): Signal<T | undefined> {
  // Fail immediately with a helpful message if called outside injection context
  assertInInjectionContext(createSignalFromObservable);

  const result = signal<T | undefined>(undefined);
  const destroyRef = inject(DestroyRef);

  observableFactory()
    .pipe(takeUntilDestroyed(destroyRef))
    .subscribe(value => result.set(value));

  return result.asReadonly();
}

// This works — called from a field initializer (injection context is active)
@Component({
  selector: 'app-data-viewer',
  template: `
    @if (userData()) {
      <pre>{{ userData() | json }}</pre>
    }
  `,
  standalone: true,
  imports: [JsonPipe]
})
export class DataViewerComponent {
  private userService = inject(UserService);

  userData = createSignalFromObservable(() => this.userService.getCurrentUser());
}

Debugging Injection Context

This helper can be useful during development to verify whether a code path is running inside injection context:

export function debugInjectionContext(label: string): boolean {
  try {
    assertInInjectionContext(debugInjectionContext);
    console.log(`[OK] ${label}: inside injection context`);
    return true;
  } catch {
    console.error(`[FAIL] ${label}: outside injection context`);
    return false;
  }
}

@Component({
  selector: 'app-debug',
  template: `...`,
  standalone: true
})
export class DebugComponent {
  constructor() {
    debugInjectionContext('Constructor'); // Logs: [OK]
  }

  ngOnInit() {
    debugInjectionContext('ngOnInit'); // Logs: [FAIL]
  }

  someMethod() {
    debugInjectionContext('someMethod'); // Logs: [FAIL]
  }
}

ngOnInit and other lifecycle hooks run outside injection context — only constructors and field initializers are safe for inject() without runInInjectionContext.

Signals and Injection Context

Angular signals integrate naturally with the injection system. Here are two common patterns.

Reactive Service with a Signal

@Injectable({ providedIn: 'root' })
export class ThemeService {
  private storage = inject(LocalStorageService);

  private themeSignal = signal<'light' | 'dark'>(
    (this.storage.getItem('theme') as 'light' | 'dark') ?? 'light'
  );

  readonly theme = this.themeSignal.asReadonly();

  toggleTheme(): void {
    const next = this.themeSignal() === 'light' ? 'dark' : 'light';
    this.themeSignal.set(next);
    this.storage.setItem('theme', next);
  }
}

@Component({
  selector: 'app-theme-toggle',
  template: `
    <button (click)="themeService.toggleTheme()">
      @if (themeService.theme() === 'dark') {
        Switch to Light
      } @else {
        Switch to Dark
      }
    </button>
  `,
  standalone: true
})
export class ThemeToggleComponent {
  protected themeService = inject(ThemeService);
}

Computed Signal from Multiple Injected Services

@Component({
  selector: 'app-user-stats',
  template: `
    <div class="stats-grid">
      @for (stat of userStats(); track stat.label) {
        <div class="stat-card">
          <h3>{{ stat.label }}</h3>
          <p>{{ stat.value }}</p>
        </div>
      }
    </div>
  `,
  standalone: true
})
export class UserStatsComponent {
  private userService = inject(UserService);
  private analyticsService = inject(AnalyticsService);

  private user = toSignal(this.userService.currentUser$);

  userStats = computed(() => {
    const currentUser = this.user();
    if (!currentUser) return [];

    return [
      { label: 'Posts', value: currentUser.postCount },
      { label: 'Followers', value: currentUser.followerCount },
      {
        label: 'Engagement',
        value: this.analyticsService.calculateEngagement(currentUser)
      }
    ];
  });
}

Unit Testing Code That Uses Injection Context

Testing a Component with `inject()`

describe('UserProfileComponent', () => {
  let component: UserProfileComponent;
  let fixture: ComponentFixture<UserProfileComponent>;
  let userService: jasmine.SpyObj<UserService>;

  beforeEach(() => {
    const spy = jasmine.createSpyObj('UserService', ['getUser', 'updateUser']);

    TestBed.configureTestingModule({
      imports: [UserProfileComponent],
      providers: [{ provide: UserService, useValue: spy }]
    });

    fixture = TestBed.createComponent(UserProfileComponent);
    component = fixture.componentInstance;
    userService = TestBed.inject(UserService) as jasmine.SpyObj<UserService>;
  });

  it('should inject UserService', () => {
    expect(component['userService']).toBe(userService);
  });

  it('should load user data on init', () => {
    const mockUser = { id: 1, name: 'Test User' };
    userService.getUser.and.returnValue(of(mockUser));

    component.ngOnInit();

    expect(userService.getUser).toHaveBeenCalled();
    expect(component.user()).toEqual(mockUser);
  });
});

Testing a Utility That Calls `inject()`

Use TestBed.runInInjectionContext to execute functions that require injection context:

describe('logUserAction', () => {
  let injector: EnvironmentInjector;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [LoggerService, UserService]
    });

    injector = TestBed.inject(EnvironmentInjector);
  });

  it('should log the action when called inside injection context', () => {
    const loggerSpy = spyOn(TestBed.inject(LoggerService), 'log');

    TestBed.runInInjectionContext(() => {
      logUserAction('test-action');
    });

    expect(loggerSpy).toHaveBeenCalledWith(
      jasmine.objectContaining({ action: 'test-action' })
    );
  });

  it('should throw NG0203 when called outside injection context', () => {
    expect(() => logUserAction('test')).toThrowError(/NG0203/);
  });
});

Testing a Functional Guard

describe('authGuard', () => {
  let authService: jasmine.SpyObj<AuthService>;
  let router: jasmine.SpyObj<Router>;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        { provide: AuthService, useValue: jasmine.createSpyObj('AuthService', ['isAuthenticated']) },
        { provide: Router, useValue: jasmine.createSpyObj('Router', ['createUrlTree']) }
      ]
    });

    authService = TestBed.inject(AuthService) as jasmine.SpyObj<AuthService>;
    router = TestBed.inject(Router) as jasmine.SpyObj<Router>;
  });

  it('should return true when the user is authenticated', () => {
    authService.isAuthenticated.and.returnValue(true);

    const result = TestBed.runInInjectionContext(() =>
      authGuard({} as ActivatedRouteSnapshot, {} as RouterStateSnapshot)
    );

    expect(result).toBe(true);
  });

  it('should redirect to /login when not authenticated', () => {
    authService.isAuthenticated.and.returnValue(false);
    const urlTree = {} as UrlTree;
    router.createUrlTree.and.returnValue(urlTree);

    const result = TestBed.runInInjectionContext(() =>
      authGuard({} as ActivatedRouteSnapshot, { url: '/protected' } as RouterStateSnapshot)
    );

    expect(router.createUrlTree).toHaveBeenCalledWith(
      ['/login'],
      { queryParams: { returnUrl: '/protected' } }
    );
    expect(result).toBe(urlTree);
  });
});

Best Practices

Prefer inject() over constructor parameter injection. The result is less boilerplate and clearer intent, especially when a class depends on many services.

// Constructor injection — verbose at scale
@Component({ selector: 'app-old', template: `...`, standalone: true })
export class OldStyleComponent {
  constructor(
    private userService: UserService,
    private router: Router,
    private http: HttpClient
  ) {}
}

// Field injection — concise and explicit
@Component({ selector: 'app-modern', template: `...`, standalone: true })
export class ModernComponent {
  private userService = inject(UserService);
  private router = inject(Router);
  private http = inject(HttpClient);
}

Use DestroyRef for subscription cleanup. Inject DestroyRef and use takeUntilDestroyed instead of managing Subject-based teardown manually.

@Component({
  selector: 'app-live-data',
  template: `...`,
  standalone: true
})
export class LiveDataComponent {
  private destroyRef = inject(DestroyRef);
  private dataService = inject(DataService);

  data = signal<any[]>([]);

  ngOnInit() {
    this.dataService.getData()
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(data => this.data.set(data));
  }
}

Use InjectionToken with factory for platform-aware configuration.

export interface AppConfig {
  apiUrl: string;
  version: string;
}

export const APP_CONFIG = new InjectionToken<AppConfig>('APP_CONFIG');

bootstrapApplication(AppComponent, {
  providers: [
    {
      provide: APP_CONFIG,
      useFactory: () => {
        const platformId = inject(PLATFORM_ID);
        return {
          apiUrl: isPlatformBrowser(platformId) ? '/api' : 'http://localhost:3000',
          version: '2.0.0'
        };
      }
    }
  ]
});

Summary

Injection context is the runtime environment in which Angular's injector is active and inject() can resolve dependencies. It exists in:

Constructors of classes managed by Angular's DI system
Field initializers of those same classes
Factory functions in provider and InjectionToken definitions
Functional guards and resolvers (CanActivateFn, ResolveFn, etc.)

When you need injection context outside these locations, use runInInjectionContext with an EnvironmentInjector. When writing utility functions that depend on context, call assertInInjectionContext at the top to produce a clear error on misuse. In tests, use TestBed.runInInjectionContext to test any function that calls inject() directly.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Your Next npm install Could Already Be Running Malware

Rajat — Wed, 20 May 2026 13:30:00 +0000

Why installing packages the moment they drop is now a security incident waiting to happen

Here is a scenario that is no longer hypothetical.

A legitimate, widely trusted npm package publishes a new version. You run npm install — or your CI pipeline does automatically — and within seconds, before a single line of your application code executes, a postinstall script fires. It scans your filesystem for AWS credentials, GitHub tokens, npm publish tokens, and Kubernetes secrets. It ships them to a command-and-control server. Then it quietly finds every package you have publish access to on npm and injects the same payload into new versions, releasing them under your name.

You did not get phished. No one stole your password. Your two-factor authentication is still on. And you are now both a victim and, unknowingly, a propagation vector.

This is not a thought experiment. This is precisely what happened on May 11, 2026, when a threat group called TeamPCP compromised 42 packages in the @tanstack/* namespace, publishing 84 malicious versions in a six-minute window. @tanstack/react-router alone sees over 12.7 million weekly downloads. The malicious tarballs carried valid SLSA provenance — the cryptographic attestation that security tooling uses to verify packages came from a trusted source. The certificates were legitimate. They signed the attack.

By the end of that day, over 170 packages across npm and PyPI had been hit, including Mistral AI, UiPath, and the Bitwarden CLI.

If you have been thinking of dependency management as an engineering convenience problem, it is time to reframe it. It is a security problem. And one of the most effective mitigations is almost embarrassingly simple: stop installing packages the moment they are published.

Have you ever had a dependency update break something unexpected in production? Drop a comment below — I want to hear where this hit you.

Why the npm Ecosystem Became a Target

The numbers tell part of the story. The npm registry now hosts over 2.5 million packages. The average enterprise JavaScript application pulls in hundreds of transitive dependencies — packages your application does not import directly, but which exist somewhere in the resolved dependency tree. Each one is a potential entry point.

The attack surface expanded gradually, driven by several forces working together.

Maintainer burnout and abandoned packages. Many popular packages are maintained by one or two people in their spare time. When maintainers lose interest, they often hand off the package — or simply disappear. Attackers have learned to identify unmaintained high-download packages and either request maintainer access (as happened with event-stream in 2018) or simply purchase the maintainer's account credentials from data breach marketplaces. The package's download count remains, but the code is now under hostile control.

Transitive dependency explosion. When you install a framework, you are not installing one package. You are pulling in an entire dependency graph. Some of those are two or three hops away from the package you actually intended to use. Auditing what you install directly is tractable. Auditing the entire resolved tree — which can run into the hundreds of packages for a moderately sized project — is almost impossible to do manually.

Semver ranges as a silent update mechanism. Most package.json files specify dependencies with caret or tilde ranges: ^1.14.0 or ~1.14.0. This is intentional — it means patch and minor updates arrive automatically on your next install. It is also what allowed the Axios attack to propagate so effectively. Projects pinned to axios@^1.14.0 automatically resolved to the malicious 1.14.1 on their next npm install or CI run. No developer action required.

AI-generated low-quality packages. Since late 2024, the registry has seen a surge of packages generated by or with AI assistance, many of which have thin audit trails, no meaningful version history, and no active community watching for anomalies. Some are benign but poorly maintained. Others are typosquats designed to look like real packages.

Blind trust in the install-time convention. The npm ecosystem normalized a convention — postinstall scripts — that was designed for legitimate use cases like compiling native binaries, but which creates an execution surface that runs with full developer privileges the instant installation completes. This runs before your application, before your tests, and before most security tooling can inspect what actually ran.

What Actually Happens When You Run `npm install`

Most developers think of npm install as a file-copy operation. It is not. It is a code execution event.

When you run npm install, the package manager resolves your full dependency tree, downloads tarballs, unpacks them, and — critically — runs any lifecycle scripts defined in each package's package.json. The relevant hooks are:

{
  "scripts": {
    "preinstall": "runs before the package is installed",
    "install": "runs during installation",
    "postinstall": "runs after the package is installed",
    "prepare": "runs after install and before pack/publish"
  }
}

These scripts run with the same permissions as the user or process that invoked npm install. On a developer machine, that is typically your user account — with access to ~/.ssh, ~/.aws, ~/.npmrc (which contains your npm publish token), your shell history, and any environment variables you have set. On a CI runner, that means the runner's cloud credentials, OIDC tokens, and secrets injected by your pipeline.

The Axios attack exploited this directly. The malicious versions introduced a new dependency, plain-crypto-js@4.2.1, that had no presence in Axios's actual runtime code. It existed solely to execute a postinstall script that downloaded a second-stage remote access trojan. Normal application behavior was unchanged — your HTTP requests kept working. The malware ran silently at install time, then persisted.

The TanStack attack pushed this further. The worm installed a persistence daemon (com.user.gh-token-monitor.plist on macOS, a systemd user service on Linux) that polled your GitHub token every 60 seconds. If you followed the security playbook and revoked your token in response to a suspected compromise, the daemon detected the revocation and executed rm -rf ~/ — wiping your entire home directory as a retaliatory action. The correct response was the trigger.

Transitive execution is the hidden danger. When a deep dependency runs a postinstall script, you typically have no visibility into it. Your npm install output will mention it if logging is verbose, but most CI pipelines and developer workflows do not watch those logs carefully. The script runs and finishes before you see the result.

Lockfiles help, but not unconditionally. A lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) pins exact resolved versions, which prevents automatic version drift. If your lockfile pins axios@1.14.0, a new malicious 1.14.1 will not be pulled in automatically. But lockfiles require discipline. Any operation that resolves or updates the tree — npm update, npm install <new-package>, or a Renovate/Dependabot PR — can introduce new versions. And the Axios attack is a reminder that even a version explicitly installed based on a semver range can resolve to something you did not intend.

The Incident Record: What Has Already Happened

These are not hypothetical scenarios. They are documented incidents with real damage.

event-stream (2018). The event-stream package had over 1.5 million weekly downloads when a bad actor convinced the original maintainer to hand over publish access, claiming they wanted to help maintain it. The new maintainer injected a dependency targeting the copay Bitcoin wallet application. The attack went undetected for two months. The lesson: maintainer handoff is a trust event, not a routine admin action.

eslint-scope (2018). The eslint-scope package — part of the ESLint toolchain — was compromised when an attacker gained access to a maintainer's npm account via credentials stolen in a separate data breach. A malicious version was published that attempted to steal npm tokens from ~/.npmrc files and send them to a remote server. The package had millions of weekly downloads. Detection came from community monitoring, not from npm itself.

eslint-config-prettier (July 2025). A maintainer was phished via a convincing email sent from a lookalike domain. The attacker published unauthorized versions containing a postinstall script that executed a trojan DLL on Windows machines. The package had over 31 million weekly downloads at the time of compromise. The attack used a deceptive domain designed to resemble npmjs.com to steal credentials.

ua-parser-js (multiple incidents). The user agent parsing library was compromised more than once, with attackers injecting cryptocurrency miners and credential stealers. Given its reach across thousands of projects that passively depend on it through transitives, each incident resulted in broad exposure before detection.

Shai-Hulud (September 2025). In one of the largest npm supply chain attacks on record, a trusted maintainer was phished via a spoofed npm support email. Eighteen widely used packages with a combined weekly download count exceeding 2.6 billion were compromised. The malicious code targeted cryptocurrency transactions. CISA issued a public advisory. The attack was contained through community detection and not npm's own systems.

Axios (March 31, 2026). Microsoft Threat Intelligence attributed this attack to Sapphire Sleet, a North Korean state actor. Malicious versions 1.14.1 and 0.30.4 were published. They added a fake dependency that ran a postinstall script downloading a remote access trojan targeting macOS, Windows, and Linux. Projects using axios@^1.14.0 or axios@^0.30.0 resolved to the malicious versions on their next install. The trojan connected to a Sapphire Sleet command-and-control server with no visible change to Axios's behavior.

TanStack / Mini Shai-Hulud (May 11, 2026). The most technically sophisticated attack documented to date. No credentials were stolen. The attackers chained three GitHub Actions vulnerabilities — a pull_request_target Pwn Request, cache poisoning across the fork/base trust boundary, and runtime OIDC token extraction from the runner process — to publish 84 malicious packages in six minutes, all carrying valid SLSA provenance. The worm self-propagated using the victim's own publish credentials. OpenAI confirmed two employee devices were compromised. The campaign extended to over 170 packages across npm and PyPI by end of day.

The pattern across these incidents is consistent. A trusted package, a brief window of malicious publication, automatic adoption via semver ranges or CI pipelines, and detection by the community — not by the registry.

Have you audited your team's dependency update workflow recently? What does your process look like when a new version drops? Tell me in the comments.

Why "Wait Before Installing" Is Not Paranoia

The community security researchers who discovered the TanStack attack detected it approximately 20 minutes after the first malicious publish. The Axios malicious versions were identified within hours. In most recent incidents, the window between publish and public disclosure has been measured in hours, not days.

This is the core insight: attackers benefit from immediate adoption. Defenders benefit from delay.

If an organization had a policy of not installing packages released within the last seven days — enforced at the package manager or registry level — the Axios attack would not have reached their developers or CI pipelines. The TanStack attack would not have reached them either. The malicious versions were live for roughly four hours before deprecation began. A seven-day gate would have caught them with room to spare.

OpenAI's post-incident statement made this explicit. They noted that the two impacted employee devices "did not have the updated configurations that would have prevented the download of the newly observed package containing malware" — specifically referencing minimumReleaseAge configurations that they had begun deploying after the Axios incident but had not yet fully rolled out.

The waiting strategy works because:

Most compromised packages are detected within 24–72 hours by security researchers, community monitoring tools like Socket.dev, or registry scanning
Automated adoption (Renovate/Dependabot PRs merging, CI pipelines running npm install) is the primary propagation mechanism — any gate on version freshness interrupts that propagation
Malicious versions are typically removed or deprecated quickly once discovered, but only help organizations that have not already installed them
A brief delay has minimal practical cost for most dependency updates, which are not time-critical

The argument against waiting — that you need the latest security patches immediately — is real but addressable. The solution is an exclusion list for packages where you have an active vulnerability and are installing a confirmed-clean remediation version. That is a deliberate, audited decision, not an automatic update.

How Every Major Package Manager Now Supports This

All four major JavaScript package managers shipped native support for minimum release age gates. They arrived within months of each other, which suggests the ecosystem recognized the same threat simultaneously.

| Manager | Config File            | Unit    | Default  |
|---------|------------------------|---------|----------|
| pnpm    | pnpm-workspace.yaml    | minutes | 1 day    |
| Yarn    | .yarnrc.yml            | string  | none     |
| Bun     | bunfig.toml            | seconds | none     |
| npm     | .npmrc                 | days    | none     |

pnpm was the first to ship, introducing minimumReleaseAge in v10.16 (September 2025). As of pnpm 11, it defaults to one day — the only manager that enables this out of the box.

# pnpm-workspace.yaml
minimumReleaseAge: 10080   # 7 days in minutes

minimumReleaseAgeExclude:
  - "@yourorg/*"
  - "some-critical-patch-package"

Yarn shipped npmMinimalAgeGate in v4.10.0, supporting both raw minutes and human-readable duration strings.

# .yarnrc.yml
npmMinimalAgeGate: "7d"

npmPreapprovedPackages:
  - "@yourorg/*"
  - "typescript"

Bun added minimumReleaseAge in v1.3. The value is in seconds. Bun's own repository uses a three-day gate.

# bunfig.toml
[install]
minimumReleaseAge = 604800   # 7 days in seconds

minimumReleaseAgeExcludes = ["@types/bun", "typescript"]

npm shipped min-release-age in v11.10.0 (February 2026). The value is in days and has no exclusion mechanism yet.

# .npmrc
min-release-age=7

Setting one of these takes under a minute. The protection is real and meaningful.

npm vs Yarn vs pnpm: How Lifecycle Scripts Behave Differently

The three managers handle install-time script execution differently, and those differences matter for security posture.

npm runs lifecycle scripts by default for all packages. You can disable them globally with --ignore-scripts, but this is a blunt instrument — it also prevents legitimate native build steps from running. npm has no per-package script opt-in mechanism at the lockfile level.

# Disable all scripts globally (blunt, often breaks native packages)
npm install --ignore-scripts

# Check for postinstall hooks before installing
npm pack <package> --dry-run

pnpm gives you finer control. You can opt into scripts per package and audit which packages are requesting execution rights:

# pnpm-workspace.yaml
onlyBuiltDependencies:
  - esbuild
  - sharp
  - node-gyp
  - "@parcel/watcher"

With this configuration, only the named packages are allowed to run lifecycle scripts. Everything else installs silently. This is arguably the most important security configuration in pnpm and worth adopting regardless of your minimum age policy.

Yarn supports enableScripts: false in .yarnrc.yml, disabling all install-time scripts globally. It also supports unsafeHttpWhitelist and other registry controls that give enterprises granular policy control.

pnpm's content-addressable store is worth understanding. pnpm stores packages in a central content-addressed store (typically ~/.pnpm-store) and creates hard links into node_modules. This means a given package version is physically stored once per machine, regardless of how many projects use it. It also means that if a malicious version is installed anywhere on the machine, its content is present in the global store — a nuance worth considering in shared CI environments.

Lockfile determinism. All three managers support frozen lockfile installs in CI, which is non-negotiable for security:

# npm
npm ci

# Yarn
yarn install --immutable

# pnpm
pnpm install --frozen-lockfile

npm ci (or its equivalents) deletes node_modules and installs exactly the versions in the lockfile, failing if there is any discrepancy. This prevents resolution drift on CI even when developers update packages locally. If your CI uses npm install instead of npm ci, fix that first — it is a simpler and more immediate win than almost anything else in this article.

Practical Defensive Workflows

The following are concrete steps, not theoretical recommendations.

Pin exact versions for high-risk packages. For packages with broad filesystem access or network capabilities — package managers themselves, CLI tools, build tooling — prefer exact version pins over semver ranges:

{
  "dependencies": {
    "axios": "1.14.0",
    "lodash": "4.17.21"
  },
  "devDependencies": {
    "eslint": "9.26.0",
    "typescript": "5.8.3"
  }
}

Exact pinning means updates require a deliberate change to package.json, not just a fresh install. It is friction by design.

Use npm ci in every CI pipeline — no exceptions:

# GitHub Actions example
- name: Install dependencies
  run: npm ci
  env:
    NODE_ENV: production

Audit scripts before installing unfamiliar packages:

# Inspect the package tarball before installation
npm pack <package-name> --dry-run

# View lifecycle scripts defined in a package
npm info <package-name> scripts

# Check for postinstall specifically
cat node_modules/<package-name>/package.json | jq '.scripts'

Set up minimum release age in your package manager config. The commands above give you the syntax. Set a seven-day gate for all projects not subject to emergency patching workflows. For monorepos with internal packages published to your own registry, use the exclusion list to bypass the gate.

Use Socket.dev for dependency scanning. Socket monitors npm packages in real time and alerts on suspicious patterns — new maintainers, unusual postinstall scripts, network calls in install hooks, and high-entropy strings that suggest obfuscation. It integrates with GitHub and has a free tier. The TanStack attack was detected in part through this kind of monitoring.

Configure Renovate with approval gates. If you use Renovate for automated dependency updates, require a human review step before merging dependency PRs for production packages:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "matchPackagePatterns": ["*"],
      "automerge": false,
      "reviewersFromCodeOwners": true,
      "minimumReleaseAge": "7 days"
    },
    {
      "matchPackagePatterns": ["@yourorg/*"],
      "automerge": true,
      "minimumReleaseAge": "0 days"
    }
  ]
}

Run dependencies in isolated environments. The TanStack attack postmortem recommended that developers not run npm install directly on their host OS but instead use Docker dev containers or VMs. If a postinstall script executes malware, the blast radius is the container — not your ~/.ssh directory.

# devcontainer.json (VSCode Dev Containers)
{
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "postCreateCommand": "npm ci",
  "remoteUser": "node"
}

Do not store secrets in .env files reachable by npm scripts. Use a proper secrets manager. The postinstall attack surface exists because secrets live in plaintext files that any process running as your user can read. If you use Doppler, Infisical, AWS SSO, or similar, secrets are not sitting on disk for a lifecycle script to find.

Enterprise Governance: Going Beyond the Developer Laptop

Individual practices matter, but organizations managing multiple teams and hundreds of repositories need structural approaches.

Private registries with quarantine policies. Tools like Artifactory, Verdaccio, and Cloudsmith allow you to mirror the npm registry through an internal proxy. You can configure this proxy to hold newly published versions in quarantine for a defined period before making them available to internal consumers. This enforces the minimum age policy at the infrastructure level, not just at the developer config level — meaning it applies to all teams uniformly, even those who have not updated their local configuration.

Developer -> Artifactory proxy -> [7-day quarantine buffer] -> npm registry

SBOM generation and tracking. A Software Bill of Materials gives you an auditable record of every dependency in your application, including transitive dependencies, at the time of each build. SBOM generation tools like cyclonedx-npm or syft produce machine-readable inventories that can be diffed between builds to identify new packages entering the tree:

# Generate an SBOM for your npm project
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Or using Syft
syft packages dir:. -o cyclonedx-json > sbom.json

If a malicious package enters your dependency tree, an SBOM diff will surface it. Without SBOM tracking, you have no systematic way to answer "what changed in our dependencies between deploy A and deploy B?"

Dependency review boards. For large engineering organizations, consider a lightweight governance process for first-time package additions. Not for every update — that would create unsustainable overhead — but for net-new packages being added to a project. A brief async review asking "do we need this, is it maintained, what does its install script do" catches a meaningful portion of risk without slowing teams down.

Monitor your CI/CD environment as aggressively as your application runtime. The Axios and TanStack attacks both targeted CI runners, not production servers. If your security monitoring does not cover GitHub Actions runner behavior, npm lifecycle script execution in CI, and outbound network traffic from build pipelines, you have a significant blind spot.

The Mindset Shift That Matters

There is a comfortable assumption embedded in how most teams think about dependencies: that the packages we install are inert artifacts. Files. That npm install is like dragging a ZIP file into a folder.

That assumption is no longer safe.

Package installation is code execution. It happens with your credentials. It happens with access to your secrets. It happens in your CI environment, which has access to your production infrastructure. And it happens automatically, at scale, across every developer machine and pipeline run in your organization.

The good news is that most of the mitigations are not hard. npm ci instead of npm install in CI. A seven-line config change to enable minimum release age. A onlyBuiltDependencies list in pnpm. Socket.dev on your repositories. These are not expensive enterprise initiatives — they are configuration decisions that take an afternoon to roll out across a team.

The teams that got hit by the Axios attack in March 2026, and by TanStack in May 2026, were not careless. They used OIDC trusted publishing. They had two-factor authentication enabled. They ran SLSA provenance checks. Those controls protected against the attack classes they were designed for. They were not sufficient for the attack classes that arrived.

Waiting seven days before installing a newly published version costs almost nothing. It would have prevented both.

What is one change you are going to make to your dependency workflow after reading this? Tell me in the comments — I read every one.

Recap: What You Should Take Away

npm install executes code — via lifecycle hooks — with your permissions, before your application runs
Malicious versions are typically detected within hours of publication, not days. A seven-day install gate means you install after the detection window, not inside it
All four major package managers (npm, pnpm, Yarn, Bun) now support minimum release age configuration natively. It takes minutes to enable
Use npm ci (or equivalent frozen lockfile installs) in all CI pipelines. If you are not doing this, fix it today before everything else
pnpm's onlyBuiltDependencies is one of the most underused security controls in the ecosystem
Private registries with quarantine buffers enforce minimum-age policies organization-wide, not just per-developer
SBOM generation gives you a dependency audit trail — you cannot detect what changed if you never tracked what existed
The threat is not hypothetical. Axios, TanStack, Bitwarden CLI, Trivy, and over 170 packages hit in a single day in May 2026 are documented incidents with real organizational impact

Bonus Tips

Tip 1: Add audit=true to your .npmrc and npm audit --audit-level=high as a CI step. It will not catch zero-day malicious packages, but it catches known CVEs that have not been applied.

Tip 2: Review which packages in your tree are requesting install-time script execution. Run npm install --ignore-scripts once, then look at what breaks. Whatever breaks legitimately is your real onlyBuiltDependencies list.

Tip 3: If you use Renovate, set minimumReleaseAge in your Renovate config as well as your package manager config. Belt and suspenders — a version that has not passed the age gate should not even generate an update PR.

Tip 4: Check your CI runners for unexpected outbound connections. Most legitimate build steps do not need to reach arbitrary external endpoints. A network egress policy on your build environment is one of the few controls that would have limited the damage from the Axios attack even if the malicious version was already installed.

What Did You Think?

I want to hear from you directly. Have you already added a minimum release age gate to your projects? Are you using pnpm with onlyBuiltDependencies? Did this change how you think about npm install?

Drop a comment below — even a quick "already doing this" or "had no idea" helps me understand what the community is actually experiencing.

Found this useful? Share it with a teammate who still runs npm install without thinking twice. That is the audience that needs it most.

Want more articles like this on JavaScript security, platform engineering, and frontend architecture? Follow me here on Medium, or subscribe to my newsletter where I publish one practical insight every week.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Stop Using JavaScript for Styles: CSS if() Function Brings Native Conditional Logic to Stylesheets

Rajat — Wed, 06 May 2026 13:30:00 +0000

CSS Finally Gets Inline Conditional Logic With New if() Function

After 25+ Years, CSS Just Got Logic: The Game-Changing if() Function That's Rewriting Styling Rules

Have you ever felt like CSS was holding you back? You know that moment when you're writing yet another media query at the bottom of your stylesheet, or creating multiple CSS classes just to handle a simple conditional style, and you think, "There has to be a better way"?

Well, that frustration just became history. CSS now has genuine conditional logic with the new if() function, and it's changing everything we thought we knew about styling web applications.

For 25+ years, developers have been asking the same question on Stack Overflow: "Does CSS have if/else statements?" The answer was always no—until now. The W3C has finally added the if() function to the CSS 2025 snapshot, and Chrome 137+ already supports it. This isn't just another CSS trick; it's a fundamental shift in how we write styles.

By the end of this article, you'll understand how the if() function works, when to use it over traditional approaches, and how to implement it in real-world scenarios with working code examples. You'll also learn about browser support strategies and future-proofing your styles.

Let's dive into the feature that's making CSS feel like a true programming language.

What Is the CSS if() Function?

Think about how you write conditional logic in JavaScript:

const color = isDarkMode ? '#ffffff' : '#000000';

The if() function brings that same inline conditional thinking to CSS. Instead of scattering your conditional logic across multiple media queries, classes, or JavaScript functions, you can now write it directly in your property values.

Here's the basic syntax:

.element {
  property: if(
    condition-1: value-1;
    condition-2: value-2;
    else: fallback-value;
  );
}

Notice the semicolons separating each condition-value pair, and the colon separating conditions from values. This syntax feels familiar if you've worked with ternary operators, but it's uniquely CSS.

The Three Types of Conditions

The if() function works with three powerful condition types:

1. Style Queries: Check Custom Property Values

Style queries let you check the value of CSS custom properties (variables) and apply different styles accordingly:

.card {
  --theme: dark;

  background-color: if(
    style(--theme: dark): #1a1a1a;
    style(--theme: light): #ffffff;
    else: #f0f0f0;
  );

  color: if(
    style(--theme: dark): #e0e0e0;
    else: #333333;
  );
}

This is incredibly powerful. You can set a single custom property and let the entire component's styling cascade from that decision. No more class-based theme switching with dozens of overrides.

2. Media Queries: Inline Responsive Design

Instead of writing separate media query blocks, bring your responsive logic inline:

.hero-title {
  font-size: if(
    media(width > 1200px): calc(3rem + 2vw);
    media(width > 768px): 2.5rem;
    else: 2rem;
  );

  padding: if(
    media(width > 768px): 4rem 2rem;
    else: 2rem 1rem;
  );
}

See what happened there? Your responsive behavior lives right next to the properties they affect. No more scrolling to the bottom of your file to find that one media query that's breaking your layout.

3. Feature Queries: Progressive Enhancement Built-In

Test for browser feature support and provide fallbacks automatically:

.gradient-box {
  background: if(
    supports(color: oklch(0.7 0.185 232)): oklch(0.7 0.185 232);
    supports(color: lab(70% 30 -45)): lab(70% 30 -45);
    else: #00adf3;
  );
}

This eliminates the need for separate @supports rules while keeping your code organized and maintainable.

Real-World Example: A Dynamic Theme System

Let's build something practical—a component that adapts to user preferences without JavaScript. Here's a complete card component with dynamic theming:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Dynamic Theme Card</title>
  <style>
    * {
      margin: 0;
      padding: 0;
      box-sizing: border-box;
    }

    body {
      font-family: system-ui, -apple-system, sans-serif;
      padding: 2rem;
      background: #f5f5f5;
    }

    .theme-controls {
      margin-bottom: 2rem;
      display: flex;
      gap: 1rem;
    }

    .theme-btn {
      padding: 0.75rem 1.5rem;
      border: none;
      border-radius: 8px;
      cursor: pointer;
      font-weight: 600;
      transition: transform 0.2s;
    }

    .theme-btn:hover {
      transform: translateY(-2px);
    }

    .card {
      --theme: ocean;
      max-width: 600px;
      padding: 2rem;
      border-radius: 12px;
      transition: all 0.3s ease;

      background: if(
        style(--theme: ocean): linear-gradient(135deg, #667eea 0%, #764ba2 100%);
        style(--theme: sunset): linear-gradient(135deg, #f093fb 0%, #f5576c 100%);
        style(--theme: forest): linear-gradient(135deg, #4facfe 0%, #00f2fe 100%);
        else: linear-gradient(135deg, #a8edea 0%, #fed6e3 100%);
      );

      color: if(
        style(--theme: ocean): #ffffff;
        style(--theme: sunset): #ffffff;
        style(--theme: forest): #003d3d;
        else: #333333;
      );

      box-shadow: if(
        style(--theme: ocean): 0 20px 60px rgba(102, 126, 234, 0.4);
        style(--theme: sunset): 0 20px 60px rgba(245, 87, 108, 0.4);
        style(--theme: forest): 0 20px 60px rgba(79, 172, 254, 0.4);
        else: 0 10px 30px rgba(0, 0, 0, 0.1);
      );
    }

    .card-header {
      margin-bottom: 1rem;
    }

    .card-title {
      font-size: if(
        media(width > 768px): 2.5rem;
        else: 2rem;
      );

      font-weight: 700;
      margin-bottom: 0.5rem;
    }

    .card-subtitle {
      opacity: if(
        style(--theme: forest): 0.7;
        else: 0.85;
      );

      font-size: 1.125rem;
    }

    .card-content {
      line-height: 1.6;
      margin-bottom: 1.5rem;
    }

    .card-footer {
      display: flex;
      gap: 1rem;
    }

    .btn {
      padding: 0.75rem 1.5rem;
      border: none;
      border-radius: 8px;
      font-weight: 600;
      cursor: pointer;
      transition: all 0.2s;

      background: if(
        style(--theme: ocean): rgba(255, 255, 255, 0.2);
        style(--theme: sunset): rgba(255, 255, 255, 0.2);
        style(--theme: forest): rgba(0, 61, 61, 0.1);
        else: rgba(0, 0, 0, 0.1);
      );

      color: inherit;

      border: if(
        style(--theme: ocean): 2px solid rgba(255, 255, 255, 0.5);
        style(--theme: sunset): 2px solid rgba(255, 255, 255, 0.5);
        style(--theme: forest): 2px solid rgba(0, 61, 61, 0.3);
        else: 2px solid rgba(0, 0, 0, 0.2);
      );
    }

    .btn:hover {
      transform: translateY(-2px);

      background: if(
        style(--theme: ocean): rgba(255, 255, 255, 0.3);
        style(--theme: sunset): rgba(255, 255, 255, 0.3);
        style(--theme: forest): rgba(0, 61, 61, 0.2);
        else: rgba(0, 0, 0, 0.15);
      );
    }
  </style>
</head>
<body>
  <div class="theme-controls">
    <button class="theme-btn" onclick="setTheme('ocean')" style="background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); color: white;">Ocean Theme</button>
    <button class="theme-btn" onclick="setTheme('sunset')" style="background: linear-gradient(135deg, #f093fb 0%, #f5576c 100%); color: white;">Sunset Theme</button>
    <button class="theme-btn" onclick="setTheme('forest')" style="background: linear-gradient(135deg, #4facfe 0%, #00f2fe 100%); color: #003d3d;">Forest Theme</button>
  </div>

  <div class="card" id="themeCard">
    <div class="card-header">
      <h2 class="card-title">Welcome to CSS if() Functions</h2>
      <p class="card-subtitle">Dynamic theming without JavaScript overhead</p>
    </div>

    <div class="card-content">
      <p>This card demonstrates the power of CSS if() functions with inline conditional logic. Click the theme buttons above to see the entire component transform—colors, shadows, borders, and opacity all update based on a single custom property.</p>
      <p style="margin-top: 1rem;">Notice how responsive the design is: the title size adjusts based on viewport width, and all theme variations remain perfectly readable across different screen sizes.</p>
    </div>

    <div class="card-footer">
      <button class="btn">Learn More</button>
      <button class="btn">Get Started</button>
    </div>
  </div>

  <script>
    function setTheme(theme) {
      document.getElementById('themeCard').style.setProperty('--theme', theme);
    }
  </script>
</body>
</html>

Open this in Chrome 137+ and watch how clicking theme buttons transforms the entire card. One custom property controls everything: gradient backgrounds, text colors, shadows, button styles, and even opacity values.

The magic here is that all the conditional logic lives in CSS, not JavaScript. The JS only sets a single custom property value. Everything else is declarative, performant, and maintainable.

When to Use if() Over Traditional Approaches

You might be thinking, "I can already do this with media queries and classes." You're right, but here's when if() shines:

Use if() when:

You need property-level conditions rather than entire rule blocks
Your conditions are based on custom property values that change dynamically
You want inline responsive tweaks without separate media queries
You're building component-level themes that need tight coupling with their properties

Stick with traditional approaches when:

You're applying many different properties based on a single condition (media queries are cleaner)
You need broad layout changes affecting multiple elements (container queries excel here)
You're working with older browser support requirements

Think of it this way: media queries are great for layout orchestration, while if() excels at granular property decisions.

Browser Support Reality Check

Here's the situation as of December 2025: if() is supported in Chrome 137+, Edge 137+, and Chrome for Android. Firefox and Safari are still in development.

This means you need a progressive enhancement strategy:

.element {
  /* Baseline style that works everywhere */
  background: #00adf3;
  color: #ffffff;
  padding: 1rem;

  /* Enhanced styles for supporting browsers */
  background: if(
    style(--theme: dark): #1a1a1a;
    style(--theme: light): #ffffff;
    else: #00adf3;
  );

  color: if(
    style(--theme: dark): #e0e0e0;
    style(--theme: light): #333333;
    else: #ffffff;
  );
}

Browsers that don't support if() will ignore those declarations and stick with your baseline styles. Browsers with support get the enhanced experience. This is CSS's built-in progressive enhancement at work.

What's your current strategy for handling browser compatibility? Drop a comment and let's discuss different approaches.

Advanced Pattern: Nesting if() Functions

Here's where things get really interesting. You can nest if() functions for complex conditional logic:

.notification {
  --status: warning;
  --size: large;

  background: if(
    style(--status: error): if(
      style(--size: large): #dc2626;
      else: #ef4444;
    );
    style(--status: warning): if(
      style(--size: large): #d97706;
      else: #f59e0b;
    );
    style(--status: success): if(
      style(--size: large): #16a34a;
      else: #22c55e;
    );
    else: #6b7280;
  );

  padding: if(
    style(--size: large): 2rem;
    style(--size: medium): 1.5rem;
    else: 1rem;
  );

  font-size: if(
    style(--size: large): 1.25rem;
    style(--size: medium): 1rem;
    else: 0.875rem;
  );
}

This creates a notification system where both status and size affect the styling. The nested if() for background color checks status first, then size, providing four different shades of each status color.

Combining if() with calc() for Dynamic Sizing

Here's a pattern that's incredibly useful for fluid typography and spacing:

.responsive-section {
  --viewport-size: large;

  padding: if(
    media(width > 1200px): calc(4rem + 2vw);
    media(width > 768px): calc(3rem + 1.5vw);
    else: calc(2rem + 1vw);
  );

  font-size: if(
    style(--viewport-size: large): clamp(1.25rem, 2vw, 2rem);
    style(--viewport-size: medium): clamp(1rem, 1.5vw, 1.5rem);
    else: clamp(0.875rem, 1vw, 1.125rem);
  );
}

By combining if() with calc() and clamp(), you create sophisticated responsive sizing that adapts smoothly across breakpoints while maintaining readable constraints.

Common Pitfalls and How to Avoid Them

After working with if() extensively, here are the gotchas I've encountered:

1. Forgetting the semicolons between conditions

/* Wrong */
color: if(
  style(--theme: dark): #ffffff
  else: #000000
);

/* Correct */
color: if(
  style(--theme: dark): #ffffff;
  else: #000000;
);

2. Using commas instead of semicolons

CSS developers are used to comma-separated values. With if(), semicolons separate condition-value pairs. This trips people up constantly.

3. Not providing an else fallback

Without an else, if no conditions match, the property becomes invalid in supporting browsers. Always include that else clause for predictable behavior.

4. Over-nesting

While nesting is powerful, more than two levels becomes hard to read. Consider refactoring deeply nested if() functions into separate custom properties.

Have you hit any other issues? Share your experience in the comments so others can learn from it.

Performance Considerations

One question I get frequently: "Does if() impact performance?"

The answer is nuanced. The if() function evaluates at style computation time, just like any other CSS function. For most use cases, the performance impact is negligible—likely faster than JavaScript-based conditional styling.

However, be mindful when:

Using if() with expensive calculations inside calc() or complex gradients
Creating deeply nested if() functions with many conditions
Applying if() to animated properties that update frequently

In these scenarios, test performance with your browser's developer tools. Profile your styles and measure frame rates during animations.

The Future: Where if() Is Heading

The CSS Working Group isn't done yet. Here's what's on the horizon:

CSS @function: Custom functions that can use if() internally, creating reusable conditional logic

Enhanced style queries: Range checking within if() for more sophisticated conditions

Better integration with View Transitions: Conditional styles during page transitions

Expanded media query support: New media features specifically designed for if() usage

This is just the beginning. The if() function opens architectural possibilities we haven't fully explored yet.

Practical Tips for Adoption

Ready to start using if() in your projects? Here's my recommended approach:

Start small: Begin with a single component that has simple theming needs

Build a token system: Use CSS custom properties as your design tokens, then let if() orchestrate them

Document your conditions: Add comments explaining what each if() is checking—future you will appreciate it

Test progressively: Verify your baseline styles work, then enhance with if() for supporting browsers

Share learnings: The community is still discovering best practices—document what works for you

What would you build with if() if it had full browser support tomorrow? I'm genuinely curious about the creative applications developers will dream up.

Bonus Tips for Mastering if()

Tip 1: Use CSS Custom Properties as Feature Flags

:root {
  --enable-advanced-effects: true;
}

.component {
  backdrop-filter: if(
    style(--enable-advanced-effects: true): blur(10px);
    else: none;
  );
}

This pattern lets you toggle expensive effects across your entire app with one variable change.

Tip 2: Create Semantic Status Systems

Instead of hardcoding colors everywhere, use if() with semantic status properties:

.status-indicator {
  --status: idle;

  --status-color: if(
    style(--status: active): #22c55e;
    style(--status: pending): #f59e0b;
    style(--status: error): #ef4444;
    else: #6b7280;
  );

  background: var(--status-color);
  border-left: 4px solid var(--status-color);
}

Now your status colors are centralized and consistent.

Tip 3: Responsive Component Variants

.button {
  --variant: primary;

  padding: if(
    media(width > 768px): 1rem 2rem;
    else: 0.75rem 1.5rem;
  );

  background: if(
    style(--variant: primary): #3b82f6;
    style(--variant: secondary): #6b7280;
    style(--variant: danger): #ef4444;
    else: transparent;
  );

  color: if(
    style(--variant: primary): white;
    style(--variant: secondary): white;
    style(--variant: danger): white;
    else: currentColor;
  );
}

This creates a button system with variants that adapt responsively without writing separate component classes.

Recap: What We've Learned

The CSS if() function is a game-changer that brings real conditional logic to stylesheets for the first time:

Three condition types: style queries, media queries, and feature queries give you flexible conditional options
Inline logic: Keep your conditional styling right next to the properties they affect for better maintainability
Progressive enhancement: Build baseline styles first, then enhance with if() for supporting browsers
Performance-friendly: Evaluates at style computation time with minimal overhead
Semantic power: Combine with custom properties to create expressive, theme-aware components
Future-ready: Opens new architectural patterns as browser support grows

The syntax takes a bit of getting used to (remember those semicolons!), but once it clicks, you'll find yourself reaching for if() in situations where you previously needed JavaScript or complex CSS workarounds.

Whether you're building design systems, component libraries, or one-off projects, if() gives you a more elegant way to express conditional styling logic. Start experimenting with it in Chrome today, and you'll be ready when broader browser support arrives.

Found This Helpful?

If this article saved you from writing a hundred extra CSS classes or helped you understand how if() actually works, hit that clap button. The more claps this gets, the more developers discover this game-changing feature.

And seriously, don't be shy with those claps—you can clap up to 50 times. Every clap helps other developers find this content and learn about CSS's evolution.

Action Points:

Try the if() function in Chrome 137+ today with the code examples above
Build a small component using conditional styling to get comfortable with the syntax
Share this article with your team to discuss adoption strategies
Check the MDN documentation for the latest browser support updates
Experiment with nested if() functions to unlock advanced patterns

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

Temporal vs Date vs Intl: Which JavaScript API Should You Use? (Real Examples)

Rajat — Tue, 28 Apr 2026 13:30:00 +0000

Finally, a modern solution to JavaScript's 25-year-old date nightmare that actually makes sense

Picture this: You're debugging a production issue at 2 AM. The bug? JavaScript's Date object thinks February 30th is a valid date and happily rolls it over to March. Sound familiar?

Quick question for you: How many times have you pulled your hair out trying to handle timezones in JavaScript? Drop a number in the comments — I'm betting it's more than 10!

If you've ever written new Date() and immediately regretted it, you're not alone. JavaScript's Date API has been the bane of developers' existence since 1995. But here's the good news — the new Temporal API is here to save us all.

By the end of this article, you'll learn:

Why Date API fails us (with shocking examples)
How Temporal API fixes every major date problem
When to use Intl for formatting vs actual date logic
Real-world edge cases and which API handles them best
A decision framework for choosing the right tool

Let's dive in!

The Problem: Why Date API Makes Developers Cry

The Classic Timezone Disaster

Here's a fun one. Try this in your console right now:

// Creating a date in New York timezone
const nyDate = new Date('2024-03-10 02:30:00');
console.log(nyDate.toString());
// Result varies based on YOUR timezone! 

// Even worse - DST transitions
const beforeDST = new Date('2024-03-10 01:30:00');
const afterDST = new Date('2024-03-10 03:30:00');
console.log(afterDST - beforeDST);
// Should be 2 hours, but... surprise!

Tell me in the comments: Have you ever had a bug caused by DST transitions? I once had a scheduling system book meetings in the past because of this!

The Month Indexing Madness

// Pop quiz: What date is this?
const date = new Date(2024, 11, 25);
console.log(date.toDateString());
// "Wed Dec 25 2024" - because months are 0-indexed 

// But wait, days aren't!
const weirdDate = new Date(2024, 1, 30); // Feb 30?
console.log(weirdDate.toDateString());
// "Fri Mar 01 2024" - It just... rolls over?!

If this saved you from a future bug, hit that button! Your future self will thank you.

Enter Temporal API: The Hero We Deserve

The Temporal API isn't just an improvement — it's a complete reimagining of how dates should work. Let's see it in action:

Crystal Clear Date Creation

// With Temporal - what you see is what you get
const date = Temporal.PlainDate.from('2024-12-25');
console.log(date.toString()); // "2024-12-25"

// Months are FINALLY 1-indexed!
const christmas = Temporal.PlainDate.from({
  year: 2024,
  month: 12, // December is 12!
  day: 25
});

// Invalid dates throw errors instead of rolling over
try {
  const invalid = Temporal.PlainDate.from({
    year: 2024,
    month: 2,
    day: 30
  });
} catch (e) {
  console.log("Error: Invalid date!"); // This actually happens!
}

Timezone Handling That Actually Works

// Temporal separates dates, times, and timezones
const nyTime = Temporal.ZonedDateTime.from({
  timeZone: 'America/New_York',
  year: 2024,
  month: 3,
  day: 10,
  hour: 2,
  minute: 30
});

// Convert to LA time
const laTime = nyTime.withTimeZone('America/Los_Angeles');
console.log(laTime.hour); // Correctly adjusted!

// Duration calculations that make sense
const meeting = Temporal.PlainDateTime.from('2024-01-15T14:00');
const deadline = Temporal.PlainDateTime.from('2024-01-20T18:00');
const timeLeft = deadline.since(meeting);
console.log(`${timeLeft.days} days, ${timeLeft.hours} hours`);
// "5 days, 4 hours" - No manual math needed!

Quick check: Are you already thinking about refactoring your date code? Let me know what feature excites you most!

Intl API: The Formatting Specialist

While Temporal handles date logic, Intl shines at formatting. Here's when to use each:

Intl for Localization

const date = new Date('2024-12-25');

// Format for different locales
const usFormat = new Intl.DateTimeFormat('en-US').format(date);
console.log(usFormat); // "12/25/2024"

const ukFormat = new Intl.DateTimeFormat('en-GB').format(date);
console.log(ukFormat); // "25/12/2024"

const jpFormat = new Intl.DateTimeFormat('ja-JP').format(date);
console.log(jpFormat); // "2024/12/25"

// Relative time formatting (perfect for "3 days ago")
const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });
console.log(rtf.format(-3, 'day')); // "3 days ago"
console.log(rtf.format(2, 'hour')); // "in 2 hours"

Advanced Formatting Options

const options = {
  weekday: 'long',
  year: 'numeric',
  month: 'long',
  day: 'numeric',
  hour: '2-digit',
  minute: '2-digit',
  timeZoneName: 'short'
};

const formatter = new Intl.DateTimeFormat('en-US', options);
console.log(formatter.format(new Date()));
// "Monday, December 25, 2024 at 10:30 AM EST"

The Ultimate Comparison: Real-World Scenarios

Let's solve actual problems with each API:

Scenario 1: Calculate Business Days Between Dates

// Date API (painful)
function businessDaysDiff_Date(start, end) {
  let count = 0;
  let current = new Date(start);

  while (current <= end) {
    const day = current.getDay();
    if (day !== 0 && day !== 6) count++;
    current.setDate(current.getDate() + 1); // Mutates! 
  }
  return count;
}

// Temporal API (elegant)
function businessDaysDiff_Temporal(start, end) {
  let count = 0;
  let current = start;

  while (Temporal.PlainDate.compare(current, end) <= 0) {
    if (current.dayOfWeek <= 5) count++;
    current = current.add({ days: 1 }); // Immutable! 
  }
  return count;
}

Scenario 2: Schedule Recurring Meetings

//  Temporal shines here
function scheduleWeeklyMeeting(startDate, weeks) {
  const meetings = [];
  let current = Temporal.PlainDateTime.from(startDate);

  for (let i = 0; i < weeks; i++) {
    meetings.push(current);
    current = current.add({ weeks: 1 });
  }

  return meetings;
}

// With timezone awareness
function scheduleMeetingAcrossTimezones(dateTime, timezones) {
  const base = Temporal.ZonedDateTime.from({
    ...dateTime,
    timeZone: timezones[0]
  });

  return timezones.map(tz => ({
    timezone: tz,
    localTime: base.withTimeZone(tz).toPlainDateTime()
  }));
}

Try this yourself: Which timezone handling nightmare have you faced? Share your horror story below!

Unit Testing Your Date Logic

Since you're using Angular, here's how to test date functionality properly:

Testing with Jasmine/Karma

// date-utility.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { DateUtilityService } from './date-utility.service';

describe('DateUtilityService', () => {
  let service: DateUtilityService;

  beforeEach(() => {
    TestBed.configureTestingModule({});
    service = TestBed.inject(DateUtilityService);

    // Mock current date for consistent tests
    jasmine.clock().install();
    jasmine.clock().mockDate(new Date('2024-01-15T12:00:00'));
  });

  afterEach(() => {
    jasmine.clock().uninstall();
  });

  it('should calculate business days correctly', () => {
    const start = Temporal.PlainDate.from('2024-01-15'); // Monday
    const end = Temporal.PlainDate.from('2024-01-19'); // Friday

    const result = service.calculateBusinessDays(start, end);
    expect(result).toBe(5);
  });

  it('should handle timezone conversions', () => {
    const nyMeeting = service.scheduleMeeting(
      '2024-01-15T15:00:00',
      'America/New_York'
    );

    const laTime = service.convertToTimezone(nyMeeting, 'America/Los_Angeles');
    expect(laTime.hour).toBe(12); // 3 PM NY = 12 PM LA
  });

  it('should format dates for different locales', () => {
    const date = new Date('2024-12-25');

    const usFormat = service.formatDate(date, 'en-US');
    expect(usFormat).toBe('12/25/2024');

    const ukFormat = service.formatDate(date, 'en-GB');
    expect(ukFormat).toBe('25/12/2024');
  });
});

Testing Edge Cases

it('should handle DST transitions', () => {
  // Test spring forward (lose an hour)
  const beforeDST = Temporal.ZonedDateTime.from({
    timeZone: 'America/New_York',
    year: 2024,
    month: 3,
    day: 10,
    hour: 1,
    minute: 30
  });

  const afterDST = beforeDST.add({ hours: 2 });
  expect(afterDST.hour).toBe(4); // 1:30 + 2 hours = 4:30 (not 3:30!)
});

it('should reject invalid dates', () => {
  expect(() => {
    Temporal.PlainDate.from({ year: 2024, month: 2, day: 30 });
  }).toThrow();
});

Bonus Tips: When to Use Which API

Here's your cheat sheet for making the right choice:

Use Native Date When:

You need basic timestamps (created_at, updated_at)
Working with legacy codebases
Quick prototypes (but plan to refactor!)
Third-party libraries require it

Use Temporal When:

Building new applications
Complex date arithmetic
Timezone-critical applications
Recurring events/scheduling
Need immutable date operations
Working with different calendar systems

Use Intl When:

Formatting dates for display
Localizing for multiple regions
Creating relative time displays ("2 hours ago")
Currency and number formatting (bonus use!)

Pro tip: You can combine them! Use Temporal for logic, Intl for display:

// Best of both worlds
const meeting = Temporal.ZonedDateTime.from({
  timeZone: 'America/New_York',
  year: 2024,
  month: 12,
  day: 25,
  hour: 14,
  minute: 30
});

// Use Temporal for logic
const reminder = meeting.subtract({ hours: 1 });

// Use Intl for display
const formatter = new Intl.DateTimeFormat('en-US', {
  dateStyle: 'full',
  timeStyle: 'short'
});
console.log(formatter.format(reminder.toInstant().epochMilliseconds));

Quick Recap

Let's wrap up what we've learned:

Date API = 25 years of technical debt. Use only when you must.
Temporal API = The future of JavaScript dates. Immutable, timezone-aware, and actually makes sense.
Intl API = Your formatting Swiss Army knife. Perfect for localization.
Edge cases matter = DST, leap years, and invalid dates will haunt you. Temporal handles them all.
Test everything = Mock dates, test timezones, and validate edge cases.

The migration path is clear: start using Temporal for new features, keep Intl for formatting, and gradually phase out Date API.

Your Turn!

Alright, I've shared my date API battle scars — now it's your turn!

Drop a comment and tell me:

What's the weirdest date bug you've ever encountered?
Are you planning to use Temporal in your next project?
What date-related topic should I cover next?

Found this helpful? Give it a clap (or 50 — I won't judge!). Every clap helps other developers discover these tips!

Want more JavaScript deep dives? Follow me for weekly articles where I break down complex topics into digestible, practical guides. I promise to keep saving you from 2 AM debugging sessions!

Action Items for You:

[ ] Try the Temporal API in your browser console today
[ ] Refactor one Date function to use Temporal
[ ] Share this with a teammate who's struggling with dates
[ ] Follow me for next week's article on [Performance Optimization Secrets]

Let's build a community of developers who never have to suffer through date bugs again! See you in the comments!

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

The Silent Killer, Angular Memory Leaks: How Dynamic Components Are Slowly Destroying Your Angular App's Performance

Rajat — Wed, 22 Apr 2026 13:30:00 +0000

Why your perfectly working Angular app suddenly starts crawling—and how to fix it before users notice

Have you ever deployed an Angular app that worked flawlessly in development, only to have users complain about it getting slower and slower over time? You're not alone. There's a sneaky culprit that many Angular developers overlook: memory leaks from dynamic components.

Before we dive into the examples, a quick note: the code snippets provided here use syntax from earlier Angular versions.

Here's the thing that'll make you check your code right now: every time you create a dynamic component without properly cleaning it up, you're essentially creating a digital zombie that consumes memory forever. And unlike other bugs that crash your app immediately, memory leaks are silent assassins—they slowly drain performance until your users start abandoning your app.

What you'll learn by the end of this article:

Why dynamic components cause memory leaks (with real examples)
The exact cleanup pattern that prevents these leaks
How to write bulletproof unit tests for your cleanup logic
A bonus tip that most Angular devs miss

Quick question before we dive in: Have you ever noticed your Angular app getting sluggish after users interact with it for a while? Drop a comment—I'm genuinely curious about your experience!

The Problem: Dynamic Components That Never Die

Let's start with a real-world scenario. You're building a modal service that dynamically creates components:

@Injectable()
export class ModalService {
  private componentRef: ComponentRef<any>;

  openModal(component: any, data?: any) {
    // This creates a new component instance
    this.componentRef = this.viewContainerRef.createComponent(component);

    // Set up the component
    if (data) {
      this.componentRef.instance.data = data;
    }

    // Listen for close events
    this.componentRef.instance.onClose.subscribe(() => {
      this.closeModal();
    });
  }

  closeModal() {
    // The WRONG way - this is where the leak happens!
    this.componentRef.destroy();
  }
}

Can you spot the problem?

Here's what's happening behind the scenes:

You create a component dynamically
You set up subscriptions and event listeners
You call destroy() on the component
BUT - the component reference itself is never cleared!

This means even though the component is "destroyed," JavaScript's garbage collector can't free up the memory because there's still a reference to it.

The Solution: Proper Cleanup Pattern

Here's the correct way to handle dynamic component cleanup:

@Injectable()
export class ModalService {
  private componentRef: ComponentRef<any> | null = null;

  openModal(component: any, data?: any) {
    // Clean up any existing modal first
    if (this.componentRef) {
      this.closeModal();
    }

    this.componentRef = this.viewContainerRef.createComponent(component);

    if (data) {
      this.componentRef.instance.data = data;
    }

    // Store subscription for cleanup
    const subscription = this.componentRef.instance.onClose.subscribe(() => {
      this.closeModal();
    });

    // Store the subscription reference for cleanup
    this.componentRef.instance._subscription = subscription;
  }

  closeModal() {
    if (this.componentRef) {
      // Clean up subscription first
      if (this.componentRef.instance._subscription) {
        this.componentRef.instance._subscription.unsubscribe();
      }

      // Destroy the component
      this.componentRef.destroy();

      // Clear the reference - THIS IS THE KEY!
      this.componentRef = null;
    }
  }
}

The magic happens in these two lines:

this.componentRef.destroy();
this.componentRef = null; //  This prevents the memory leak!

Let's See It in Action: Complete Example

Here's a complete working example that shows both the problem and the solution:

// Dynamic component we'll create
@Component({
  selector: 'app-dynamic-modal',
  template: `
    <div class="modal-overlay" (click)="close()">
      <div class="modal-content" (click)="$event.stopPropagation()">
        <h3>{{title}}</h3>
        <p>{{message}}</p>
        <button (click)="close()">Close</button>
      </div>
    </div>
  `
})
export class DynamicModalComponent {
  @Input() title: string = '';
  @Input() message: string = '';
  @Output() onClose = new EventEmitter<void>();

  close() {
    this.onClose.emit();
  }
}

// Service that manages dynamic components
@Injectable()
export class DynamicModalService {
  private componentRef: ComponentRef<DynamicModalComponent> | null = null;

  constructor(
    private viewContainerRef: ViewContainerRef,
    private componentFactoryResolver: ComponentFactoryResolver
  ) {}

  openModal(title: string, message: string) {
    // Clean up existing modal
    this.closeModal();

    // Create new component
    const factory = this.componentFactoryResolver.resolveComponentFactory(DynamicModalComponent);
    this.componentRef = this.viewContainerRef.createComponent(factory);

    // Set up data
    this.componentRef.instance.title = title;
    this.componentRef.instance.message = message;

    // Listen for close event
    this.componentRef.instance.onClose.subscribe(() => {
      this.closeModal();
    });
  }

  closeModal() {
    if (this.componentRef) {
      this.componentRef.destroy();
      this.componentRef = null; // Prevent memory leak
    }
  }
}

Writing Unit Tests for Memory Leak Prevention

Here's how to write unit tests that ensure your cleanup logic works correctly:

describe('DynamicModalService', () => {
  let service: DynamicModalService;
  let viewContainerRef: ViewContainerRef;
  let fixture: ComponentFixture<TestComponent>;

  beforeEach(() => {
    TestBed.configureTestingModule({
      declarations: [TestComponent, DynamicModalComponent],
      providers: [DynamicModalService]
    });

    fixture = TestBed.createComponent(TestComponent);
    viewContainerRef = fixture.componentInstance.viewContainerRef;
    service = TestBed.inject(DynamicModalService);
    service['viewContainerRef'] = viewContainerRef;
  });

  it('should clear component reference after closing modal', () => {
    // Arrange
    service.openModal('Test Title', 'Test Message');
    expect(service['componentRef']).toBeTruthy();

    // Act
    service.closeModal();

    // Assert - This is the key test!
    expect(service['componentRef']).toBeNull();
  });

  it('should not throw error when closing non-existent modal', () => {
    // This tests defensive programming
    expect(() => service.closeModal()).not.toThrow();
  });

  it('should clean up previous modal when opening new one', () => {
    // Arrange
    service.openModal('First Modal', 'First Message');
    const firstComponentRef = service['componentRef'];
    spyOn(firstComponentRef!, 'destroy');

    // Act
    service.openModal('Second Modal', 'Second Message');

    // Assert
    expect(firstComponentRef!.destroy).toHaveBeenCalled();
  });
});

// Test component for testing
@Component({
  template: '<div></div>'
})
class TestComponent {
  constructor(public viewContainerRef: ViewContainerRef) {}
}

If this testing approach just saved you hours of debugging, hit that clap button!

The Advanced Pattern: Using OnDestroy Hook

For more complex scenarios, implement the OnDestroy hook in your dynamically created components:

@Component({
  selector: 'app-advanced-dynamic',
  template: `<!-- your template -->`
})
export class AdvancedDynamicComponent implements OnDestroy {
  private subscriptions = new SubSink(); // Using SubSink library

  ngOnInit() {
    // Add all your subscriptions to SubSink
    this.subscriptions.add(
      this.someService.getData().subscribe(data => {
        // Handle data
      })
    );
  }

  ngOnDestroy() {
    // This automatically unsubscribes from all subscriptions
    this.subscriptions.unsubscribe();
  }
}

Bonus Tip: Memory Leak Detection

Want to catch memory leaks during development? Here's a trick most Angular devs don't know:

// Add this to your service for development
private debugComponentCount = 0;

openModal(component: any, data?: any) {
  this.debugComponentCount++;
  console.log(` Active components: ${this.debugComponentCount}`);

  // ... rest of your code
}

closeModal() {
  if (this.componentRef) {
    this.componentRef.destroy();
    this.componentRef = null;
    this.debugComponentCount--;
    console.log(`🧹 Cleaned up. Active components: ${this.debugComponentCount}`);
  }
}

If your debugComponentCount keeps growing, you've got a memory leak!

Recap: Your Action Plan

Here's what you need to do right now:

Audit your dynamic components - Search your codebase for .createComponent() calls
Check your cleanup logic - Make sure you're setting component references to null
Add unit tests - Test that your cleanup logic actually works
Use the debug tip - Add component counting during development
Implement OnDestroy - For complex components with multiple subscriptions

The bottom line: Memory leaks from dynamic components are silent killers, but they're incredibly easy to prevent once you know the pattern. The key is always setting your component reference to null after destroying it.

I want to hear from you!

What did you think? Have you encountered memory leaks in your Angular apps? Share your war stories in the comments—I love hearing about real-world debugging adventures!

Want more Angular tips like this? I share practical insights every week that can save you hours of debugging. Follow me to get notified when I publish new articles!

Found this helpful? If this article helped you catch a potential memory leak (or just taught you something new), smash that clap button so other developers can discover it too. Every clap helps!

Action point for you: Go check your codebase right now. Search for .createComponent() and see if you're properly cleaning up. Then come back and tell me what you found!

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

How to Configure a Proxy in Angular for API Calls (The Right Way)

Rajat — Wed, 15 Apr 2026 13:30:00 +0000

Stop hardcoding API URLs and wrestling with CORS errors—here's the developer-friendly guide to Angular proxy configuration

Ever spent hours debugging CORS errors only to realize your API calls were hitting the wrong URL? Or worse, accidentally pushed production code with localhost:3000 hardcoded everywhere?

Here's a question for you: How many times have you opened the browser console to see that dreaded red text: "Access to XMLHttpRequest has been blocked by CORS policy"?

If you're nodding your head right now, you're in the right place. By the end of this article, you'll master Angular's proxy configuration and never have to worry about development API routing again. Plus, I'll show you some tricks that took me way too long to figure out.

Before we dive into the examples, a quick note: the code snippets provided here use syntax from earlier Angular versions.

Quick poll: Drop a comment below—what's your biggest API configuration headache? Let's commiserate together!

What You'll Learn Today

Why proxy configuration is a game-changer for local development
Step-by-step setup that actually works (with real examples)
How to handle multiple APIs like a pro
Unit testing strategies for proxied endpoints
Common pitfalls that will make you pull your hair out (and how to avoid them)

Ready? Let's dive in!

Why Do We Even Need a Proxy?

Picture this: You're building an Angular app that talks to a backend API. In production, everything lives on the same domain. But locally? Your Angular dev server runs on http://localhost:4200 while your API is on http://localhost:3000.

Enter the CORS monster.

Without a proxy, you're stuck with:

CORS errors everywhere
Hardcoded API URLs scattered across your codebase
Different configurations for dev, staging, and production
That one teammate who always forgets to change the URL back (we all know one)

The proxy is your superhero here. It intercepts API calls from your Angular app and forwards them to the right backend—no CORS drama, no URL juggling.

Setting Up Your First Proxy (The 5-Minute Version)

Let's get our hands dirty with some code. Here's the simplest proxy setup that'll solve 80% of your problems:

Step 1: Create the Proxy Configuration

Create a file called proxy.conf.json in your project root:

{
  "/api": {
    "target": "http://localhost:3000",
    "secure": false,
    "changeOrigin": true,
    "logLevel": "debug"
  }
}

What's happening here?

/api: Any request starting with /api gets proxied
target: Where to forward the requests
secure: Set to false for local development (true for HTTPS)
changeOrigin: Changes the origin header to match the target
logLevel: Shows proxy activity in your console (super helpful for debugging!)

Step 2: Update Your Angular Configuration

Modify your angular.json file:

{
  "serve": {
    "builder": "@angular-devkit/build-angular:dev-server",
    "options": {
      "browserTarget": "your-app:build",
      "proxyConfig": "proxy.conf.json"
    }
  }
}

Step 3: Update Your Service Calls

Here's where the magic happens. In your Angular service:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class UserService {
  // Notice: No hardcoded domain! Just the path
  private apiUrl = '/api/users';

  constructor(private http: HttpClient) {}

  getUsers(): Observable<User[]> {
    return this.http.get<User[]>(this.apiUrl);
  }

  getUserById(id: number): Observable<User> {
    return this.http.get<User>(`${this.apiUrl}/${id}`);
  }
}

That's it! Run ng serve and your API calls will magically work without CORS issues.

Pro tip: Having issues? Check the console for proxy logs. The logLevel: "debug" setting is your best friend here.

Level Up: Handling Multiple APIs

Real-world apps rarely talk to just one API. Here's how to proxy multiple backends like a boss:

Advanced Proxy Configuration

Create a more sophisticated proxy.conf.js (yes, .js this time):

const PROXY_CONFIG = [
  {
    context: ['/api/v1'],
    target: 'http://localhost:3000',
    secure: false,
    changeOrigin: true,
    logLevel: 'debug'
  },
  {
    context: ['/api/v2'],
    target: 'http://localhost:3001',
    secure: false,
    changeOrigin: true,
    pathRewrite: {
      '^/api/v2': '/api'  // Rewrites /api/v2/users to /api/users
    }
  },
  {
    context: ['/auth'],
    target: 'https://auth.mycompany.com',
    secure: true,
    changeOrigin: true,
    headers: {
      'X-Custom-Header': 'MyApp'
    }
  }
];

module.exports = PROXY_CONFIG;

What's new here?

context: Array of paths to proxy (more flexible than single path)
pathRewrite: Modify the URL before forwarding
headers: Add custom headers to proxied requests

Update your angular.json to use the .js file:

"proxyConfig": "proxy.conf.js"

Question for you: How many different APIs does your current project talk to? Share in the comments—I'm curious about your architecture!

Writing Unit Tests for Proxied Services

Here's something most tutorials skip—how do you test services that use proxied endpoints? Let me show you:

import { TestBed } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { UserService } from './user.service';

describe('UserService', () => {
  let service: UserService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
      providers: [UserService]
    });
    service = TestBed.inject(UserService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => {
    httpMock.verify(); // Ensure no outstanding requests
  });

  it('should fetch users from the proxied endpoint', () => {
    const mockUsers = [
      { id: 1, name: 'John Doe' },
      { id: 2, name: 'Jane Smith' }
    ];

    service.getUsers().subscribe(users => {
      expect(users.length).toBe(2);
      expect(users).toEqual(mockUsers);
    });

    // Note: We're testing against the relative URL, not the proxied target
    const req = httpMock.expectOne('/api/users');
    expect(req.request.method).toBe('GET');
    req.flush(mockUsers);
  });

  it('should handle errors gracefully', () => {
    const errorMessage = 'Server error';

    service.getUsers().subscribe(
      () => fail('Should have failed'),
      error => {
        expect(error.status).toBe(500);
      }
    );

    const req = httpMock.expectOne('/api/users');
    req.flush(errorMessage, { status: 500, statusText: 'Server Error' });
  });
});

Key testing insights:

Test against the relative URLs (/api/users), not the proxied target
Use HttpClientTestingModule to mock HTTP calls
Always verify no outstanding requests with httpMock.verify()

Common Pitfalls and How to Dodge Them

After helping dozens of developers debug proxy issues, here are the gotchas that trip everyone up:

1. The "It Works on My Machine" Problem

Issue: Proxy works locally but fails in Docker/CI.

Solution:

// proxy.conf.js
const target = process.env.API_URL || 'http://localhost:3000';

const PROXY_CONFIG = [
  {
    context: ['/api'],
    target: target,
    // ... rest of config
  }
];

2. WebSocket Connections Failing

Issue: Real-time features break with proxy.

Solution:

{
  "/socket.io": {
    "target": "http://localhost:3000",
    "ws": true,  // Enable WebSocket proxy
    "secure": false,
    "changeOrigin": true
  }
}

3. The Cookie Monster

Issue: Authentication cookies not being sent.

Solution:

{
  context: ['/api'],
  target: 'http://localhost:3000',
  secure: false,
  changeOrigin: true,
  cookieDomainRewrite: "localhost",  // Rewrite cookie domain
  withCredentials: true
}

4. POST Requests Hanging Forever

Issue: Large POST requests timeout.

Solution:

{
  context: ['/api'],
  target: 'http://localhost:3000',
  secure: false,
  changeOrigin: true,
  onProxyReq: (proxyReq, req, res) => {
    // Fix body-parser issues
    if (req.body) {
      const bodyData = JSON.stringify(req.body);
      proxyReq.setHeader('Content-Length', Buffer.byteLength(bodyData));
      proxyReq.write(bodyData);
    }
  }
}

If any of these saved you from a debugging nightmare, hit that clap button! Others need to see this too.

Bonus Tips for Power Users

1. Environment-Specific Proxy Configurations

Create multiple proxy configs for different environments:

├── proxy/
│   ├── proxy.local.conf.js
│   ├── proxy.staging.conf.js
│   └── proxy.docker.conf.js

Then in package.json:

{
  "scripts": {
    "start:local": "ng serve --proxy-config proxy/proxy.local.conf.js",
    "start:staging": "ng serve --proxy-config proxy/proxy.staging.conf.js",
    "start:docker": "ng serve --proxy-config proxy/proxy.docker.conf.js"
  }
}

2. Dynamic Proxy Bypass

Sometimes you need to skip the proxy for certain requests:

{
  context: ['/api'],
  target: 'http://localhost:3000',
  bypass: function(req, res, proxyOptions) {
    // Skip proxy for health checks
    if (req.url === '/api/health') {
      return '/health.json';  // Serve local file instead
    }
    // Skip proxy for specific headers
    if (req.headers.accept?.includes('html')) {
      return '/index.html';
    }
  }
}

3. Request/Response Interceptors

Debug or modify requests on the fly:

{
  context: ['/api'],
  target: 'http://localhost:3000',
  onProxyReq: (proxyReq, req, res) => {
    // Add authentication header
    proxyReq.setHeader('X-Special-Proxy-Header', 'foobar');
    console.log('Proxying:', req.method, req.url);
  },
  onProxyRes: (proxyRes, req, res) => {
    // Log response status
    console.log('Response:', proxyRes.statusCode);
    // Add custom header to response
    proxyRes.headers['X-Proxy-Time'] = new Date().toISOString();
  }
}

Quick Recap

Let's wrap up what we've covered:

asic proxy setup takes just 5 minutes and solves CORS issues instantly

Multiple API handling with advanced proxy configurations

Unit testing strategies that work with proxied endpoints

Common pitfalls and their battle-tested solutions

Power user tips for production-ready proxy setups

The proxy configuration might seem like a small detail, but it's one of those things that, once set up properly, makes your entire development experience smoother. No more CORS errors, no more hardcoded URLs, just clean, maintainable code.

Your Turn!

Alright, I've shown you my proxy tricks—now I want to hear from you!

What's your biggest API integration challenge? Drop a comment below. I read every single one and often write follow-up articles based on your questions.

Did this save you from CORS hell? Smash that clap button (you can clap up to 50 times—I won't judge if you go wild!)

Want more Angular deep-dives? I publish practical Angular guides every week. Follow me to get notified when the next one drops.

Challenge: Try setting up a proxy for your current project and share your before/after experience in the comments. Best story gets a shoutout in my next article!

Keep Learning

If you enjoyed this, you'll love these related articles:

"Angular Performance: 5 OnPush Change Detection Tricks"
"RxJS Patterns That Will Change How You Handle API Calls"
"The Complete Guide to Angular Environments (Dev, Staging, Production)"

P.S. Still stuck with a proxy issue? Drop your specific problem in the comments with the hashtag #ProxyHelp and I'll personally help you debug it. We're all in this together!

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

💼 LinkedIn — Let’s connect professionally
🎥 Threads — Short-form frontend insights
🐦 X (Twitter) — Developer banter + code snippets
👥 BlueSky — Stay up to date on frontend trends
🌟 GitHub Projects — Explore code in action
🌐 Website — Everything in one place
📚 Medium Blog — Long-form content and deep-dives
💬 Dev Blog — Free Long-form content and deep-dives
✉️ Substack — Weekly frontend stories & curated resources
🧩 Portfolio — Projects, talks, and recognitions
✍️ Hashnode — Developer blog posts & tech discussions
✍️ Reddit — Developer blog posts & tech discussions

DEV Community: Rajat

@Service: Angular 22's @Service Decorator: Say Goodbye to @Injectable Boilerplate - Here’s What Changes (Part 4)

A practical look at Angular's new, opinionated way to write services — what changed, why it matters, and when you should still reach for the old decorator

Why Angular introduced @Service

@Service vs @Injectable: what's actually different

Using a factory for conditional logic

Opting out of automatic root provisioning

Using the service in a component

Writing unit tests for a @Service class

Best practices for adopting @Service

When not to use @Service

Bonus tips

Recap

Follow Me for More Angular & Frontend Goodness:

Meet injectAsync(): How injectAsync() in Angular 22 Can Shrink Your Initial Bundle Without Changing Your Architecture — Here's NG 22 (Part 3)

Angular 22 quietly shipped one of the most developer-friendly DI improvements in years — and most people are still sleeping on it.

What Changed in Angular 22's Dependency Injection

The Old Way: inject() and Its Limits

Introducing injectAsync(): Lazy DI on Demand

How injectAsync() Works Under the Hood

Real-World Use Cases

Use Case 1: Feature-Gated Admin Tools

Use Case 2: On-Demand Map Integration

Comparing inject() and injectAsync() Side by Side

Unit Testing Components That Use injectAsync()

injectAsync() and the New @Service Decorator

Bundle Size: The Real Payoff

Bonus Tips

Recap

Follow Me for More Angular & Frontend Goodness:

Signal Forms Are Finally Production-Ready in Angular 22 — Here’s What Changes (Part 2)

Angular 22 graduates Signal Forms from experimental to stable — here is everything you need to know to start using them today.

Why Angular Needed Signal Forms

What Are Signal Forms?

Creating Your First Signal Form

FormRoot Explained

FormField Explained

Validation in Signal Forms

Built-in Validators

Custom Validators

The when Option

Async Validation

Debounce Support

Reactive Forms vs Signal Forms — A Direct Comparison

What is the performance story here?

Migration Guidance

Should you migrate everything right now?

Hybrid Approach

Real-World Example: User Registration Form

Unit Testing Signal Form Components

Key Takeaways

Bonus Tips

Recap

Follow Me for More Angular & Frontend Goodness:

The OnPush Default Has Arrived: A Practical Guide to Angular 22's Biggest Shift - Here's What Changes (Part 1)

A practical, code-first tour of Angular 22's biggest change-detection shift — what breaks, what doesn't, and how to migrate without surprises*

OnPush Becomes the Default Change Detection Strategy

ChangeDetectionStrategy.Default Is Now ChangeDetectionStrategy.Eager

Impact on Existing Apps: The Good News and the One Catch

Signals and OnPush: Why They Were Basically Built for Each Other

The Zoneless Future: Where This Fits in the Bigger Picture

Migration Considerations: The ng update Walkthrough

Unit Testing OnPush and Signal-Based Components

Bonus Tips

Recap

Follow Me for More Angular & Frontend Goodness:

Mastering Angular Library Entry Points: Build Modular, Tree-Shakeable Packages Like a Pro

How to create secondary entry points in Angular libraries for better modularity and smaller bundles

What Are Entry Points in Angular Libraries?

Why Multiple Entry Points Matter

The Good Stuff

The Trade-offs

Step-by-Step: Creating Your First Secondary Entry Point

Step 1: Generate Your Library

Step 2: Create the Secondary Entry Point Folder

Step 3: Configure the Secondary Entry Point

Step 4: Set Up the Public API

Step 5: Create Your Utility Services

Step 6: Update Package.json Exports

Step 7: Build and Verify

The `when` Option

Running Code in Injection Context: `runInInjectionContext`

Writing Defensive Code: `assertInInjectionContext`

Testing a Component with `inject()`

Testing a Utility That Calls `inject()`

What Actually Happens When You Run `npm install`