Why I'm not upgrading to Angular 22

Angular 22 came out on June 3rd, 2026. I have a personal project (confidential for now, so I'll talk about it in generic terms) with several Angular applications and a shared library between them, managed with Nx. And that project is still on Angular 21.

It's not because I forgot to upgrade. I studied the migration, looked at it dependency by dependency, and the conclusion was: it's not time yet. In this article I'll explain why, tool by tool, in the simplest way I can. If you've never touched Angular, the idea is that you'll understand it anyway.

First: what does "upgrading Angular" mean?

Angular is a framework, meaning it's the foundation the entire front-end is built on. But no real project uses only Angular. Around it there's a whole set of libraries and tools, and each of them was built to work with a specific version of Angular.

This is declared in something called a peer dependency. It's basically the library saying "I work with Angular 21, and only with Angular 21". When you try to install a combination that doesn't match, npm (the JavaScript package installer) simply refuses.

So upgrading Angular is not upgrading one package. It's waiting for the whole ecosystem to move together. And in July 2026, a month and a half after the release, the ecosystem hasn't moved yet. Let's go through the cases.

Blocker 1: NgRx Signals

What it is: NgRx Signals is a state management library. "State" is everything the screen needs to remember: who the logged-in user is, what they loaded, what is selected. Without a library like this, each component on the screen keeps its own information in its own way and it turns into a mess fast. NgRx Signals centralizes that in one place, using signals, Angular's most recent reactivity model. All of my web apps depend on it.

Why it blocks: the most recent published version of NgRx Signals declares this:

"peerDependencies": {
  "@angular/core": "^21.0.0"
}

Translation: "I only accept Angular 21". The NgRx team releases one major version for each Angular major, and NgRx 22 simply hasn't shipped yet. They even published an official notice saying NgRx 21 "works" with Angular 22, as long as you install it with the --legacy-peer-deps flag.

And what does that flag do? It tells npm "ignore the incompatibility warnings and install anyway". Can it work? It can. But nobody tested it, nobody guarantees it, and if a weird bug shows up in production the answer will be "you installed it with the ignore-warnings flag, didn't you?". Not happening.

Blocker 2: Nx

What it is: Nx is a build orchestration tool for projects with several interdependent parts, in my case several Angular apps and a shared library between them. Nx is what keeps that organized: it knows the library needs to compile before the apps, runs builds in parallel, caches what hasn't changed so it doesn't recompile for nothing. All of my build, test and serve commands go through it.

Why it blocks: the Nx version I use explicitly locks out any Angular above 21. It's not even accidental incompatibility, there's a version check in the code, and the generators and executors fail if you try. The community opened a discussion asking for Angular 22 support the day after the release, and the Nx version with that support (23.1.0) shipped on... July 14th, 2026. Literally today, as I write this article.

And here comes a rule that everyone who has ever maintained a production system learns: you don't adopt a .0 version on release day. Let the community find the bugs first, wait for a patch or two, then go.

Blocker 3: TypeScript 6

What it is: TypeScript is the language Angular (and the whole front-end) is written in. It's JavaScript with types, which helps catch errors before running. Every tool that reads, compiles or analyzes the code depends on the TypeScript version.

Why it blocks: Angular 22 requires TypeScript 6.0. And it's not "accepts 6.0 and up", it's a closed range: it only works with TS between 6.0 and 6.1. Angular 21, in turn, only accepts TS 5.9. The ranges don't even touch, so there is no TypeScript version that serves both. The switch is mandatory and has to happen all at once.

The problem is that TypeScript isn't used only by Angular. In my project it's consumed by:

typescript-eslint, the linter, the tool that polices code quality and points out pattern violations. Their TS 6.0 support was a considerable effort (there's a public GitHub issue tracking all of it) and only recently became ready.
ng-packagr, which packages my shared library into the format the apps can consume. It needs its Angular 22-compatible version.
ng-openapi-gen, which automatically generates the communication code for my APIs from their documentation (OpenAPI). Its last release was 8 months ago, and nobody guarantees the code it generates compiles cleanly on TypeScript 6.
Plus vitest (tests), Prettier (formatting) and angular-eslint, which also read TypeScript and need to keep up.

Swapping TypeScript is like changing the standard power outlet of the house: there's no point changing only the living room one, every appliance needs the new plug on the same day.

Blocker 4: Node 20 in Docker

What it is: Node.js is the environment that runs JavaScript outside the browser. It's what executes the Angular build. And Docker is the container technology I use to package each app for deploy: each app has a Dockerfile, the recipe for assembling that package, and that recipe starts by choosing a Node base image.

Why it blocks: my pipeline is fully standardized on Node 20, an LTS (long-term support) version that serves Angular 21 perfectly. But Angular 22 dropped Node 20: the minimum is now Node 22. So on top of everything I've listed, the migration would also include swapping the base image of every Dockerfile, revalidating the entire deploy pipeline and checking that no build script changes behavior between Node versions. It's not hard, but it's one more front to work on and one more place for something to break silently.

The ones that "work, but..."

There are two dependencies in a gray zone worth mentioning:

Sentry. It's the error monitoring tool: when an error happens in the user's browser, it captures it and alerts me, stack trace and all. Its peer dependencies do accept Angular 22, but the official documentation only guarantees support up to Angular 20. Does it install? It does. Has anyone tested it thoroughly with 22? Officially, no.

Transloco. It's the internationalization (i18n) library, which makes the app translatable into several languages. It declares acceptance of any Angular from 16 onwards, an open range, so it installs on any version. But the official compatibility matrix doesn't even mention Angular 22 yet. An open range is not certification: it's the author saying "it probably works", not "I tested it".

For a learning project, "probably works" is fine. For a production system, it isn't.

And even if everything fit...

Let's suppose NgRx 22 ships tomorrow and Nx matures. There would still be the cost of Angular 22 itself, because this version changes behavior, not just API:

OnPush became the default change detection. Change detection is the mechanism that decides when Angular re-renders the screen. The old mode checked everything all the time (slower, but more forgiving). OnPush only checks when data changes in a specific way. It's faster, but every component needs to be reviewed to guarantee it keeps updating the screen as it should.
HttpClient now uses Fetch by default. It's the piece that makes the API calls. The internal engine swap (from XMLHttpRequest to Fetch) is transparent in most cases, but interceptors and edge cases need to be retested one by one.
Signal Forms became stable, the new way of building forms. Great news, but truly adopting it means refactoring form by form, not just compiling.

Conclusion

Recapping what keeps me on 21:

NgRx Signals only accepts Angular 21 and NgRx 22 doesn't exist yet
Nx support for Angular 22 shipped today, too green to trust
TypeScript 6 is mandatory and drags the linter, the library packager and the code generator along
My pipeline is standardized on Node 20 LTS, which Angular 22 stopped supporting
Sentry and Transloco install, but without officially tested support

Angular 21 remains fully supported, receives security fixes and runs all my tests green. 22 is the future and I'm going to it, but I'll go when I can go all at once, with everything fitting, instead of running ahead of the ecosystem on ignore-warnings flags and crossed fingers.

In the end, the right question is never "is the new version out yet?". It's "has my entire ecosystem gotten there?". In my case, in July 2026, the honest answer is still no.

Blog

Series

Articles