Angular zoneless lint rules: enforce signals patterns

#angular #eslint

The Angular 22 release marks the end of the transition to its new paradigm designed around signals. As it was done gradually, it felt smooth. But when adding everything, that is a lot of changes, and some may argue it is like a new framework.

But more importantly, as it was done in a backward-compatible way, the flip side is that a whole bunch of Angular features are still available and possible, while they should not be used anymore.

Lint rules

For these reasons, I created and published new lint rules: angular-eslint-zoneless.

Following the 2 steps README on GitHub, it just takes a minute to install and configure, and then:

the editor now shows when restricted legacy Angular features are used
the CI can enforce it
AI tools can follow the guidance, forcing them to use the new signals patterns

If you want to dig more, let us take a quick look at the legacy features.

No zone

The starting point is zone.js: imports, providers and zone.js specific APIs must not be used anymore.

The most impacted are unit tests, as a whole bunch of functions were designed around zone.js: fakeAsync(), waitForAsync(),...

The rules:

No bound writable properties in components

zone.js was responsible to trigger change detection on asynchronous operations, so Angular could update the UI accordingly. Now, signals handle that.

So now, when a property which is not a signal is bound to the UI and its value changes, it is not reflected in the template anymore.

The most simple way to avoid that is to not use writable public or protected properties in components.

The rules:

No eager change detection

Angular had 2 change detections strategies:

Eager (ex Default): reacts on inputs, events and asynchronous operations via zone.js; the default in Angular <= 21
OnPush: reacts only on inputs and events; the default in Angular >= 22, more performant

Given the previous points, Eager does not makes sense anymore and should not be used.

The rule:

no-eager-change-detection

No component decorators

Given that inputs and view queries values can change over time, new functions are available to handle them as signals.

So component decorators like @Input(), @ViewChild and similar should not be used anymore.

The rules:

No component lifecycle

Related to these decorators, Angular had component lifecycle methods, like ngOnInit() which was required to wait for @Input() to be ready.

But now signals are designed to be reactive. So waiting manually for the value to be ready is not necessary anymore, and lifecycle methods should not be used.

Some of them still have rare but valid use cases, so functional equivalents like afterNextRender() or destroyRef.onDestroy() are available.

The rules:

No manual detect changes

In a similar way, acting manually on the Angular change detection should not be required anymore, as signals are designed so the template always reflect their values.

The most impacted are again unit tests: fixture.detectChanges() is replaced by await fixture.whenStable().

The rules:

No bound observables in components

Components should only use signals for the state used in their templates.

Observables are still there, to manage asynchronous data (signals are not equivalent, as they are synchronous). But if their data is needed in the UI, they must be converted to signals via toSignal() or rxResource().

So the async pipe should not be used anymore, and it should generally not be necessary anymore to .subscribe() in component constructors.

The rules:

No reactive forms

Signals forms are now available and reactive forms should not be used anymore.

Despite the name, reactive forms have a lot of things that are not reactive inside the new signals paradigm, and in my own experience, it is the most risky part when migrating an existing project to zoneless.

The rule: