PSA: Angular v19 and NgRx v19

[timdeschryver]

Which @ngrx/* package(s) are relevant/related to the feature request?

signals

Information

For those looking to upgrade to NgRx v19 along with Angular v19, just wanted to post some general notes as we go through this each release cycle.

We're still working on getting the release out.

• NgRx v18 still works with Angular v19.
• Until then, you may need to install using the legacy peer deps option with npm npm i --legacy-peer-deps.
• We won't be bumping the NgRx v18 package.json to go past Angular v18 package versions. Our stance has been to keep each major release of NgRx aligned with each major release of Angular.

As this project is maintained by open source contributors in their free time, we try to work at a sustainable pace. You can support us by sponsoring the project or leveling up your team through one of our workshops.

We will have the release out as soon as its ready.

Thanks in advance,

The NgRx Team

Update 26 Nov: Version 19.0.0-beta.0 is now available, keep in mind that there will be breaking changes added in next versions before we publish a release candidate.

[michael-small]

Thanks for mentioning this, the issue like this but for when Angular 18 came out helped me.

For people who may want an alternative so the install peer deps option doesn't need to be used on the CLI / CI every time is to put the following in a package.json

// Applicable to any ngrx package
  "overrides": {
    "@ngrx/signals": {
      "@angular/common": "$@angular/common",
      "@angular/core": "$@angular/core"
    }
  }

[salztorte]

@michael-small
Is a possible workaround, but is not really something I want to have for production.
Would be nice, ngrx can be release a new version, so the workaround is not needed.

In the main branch, the dependency is already updated. Just a new release is missing.

[rainerhahnekamp]

@salztorte, once we release, there won’t be room for breaking changes for at least the next six months. Therefore, if there are features that require only a few days to implement but involve breaking changes, it’s better to address them now rather than in May 2025.

[salztorte]

@rainerhahnekamp I totally understand that a lib can not just update stuff or do breaking changes.
It just would be nice to have an EST for better planning.

[rainerhahnekamp]

Sure, this one has the breaking change and must be merged: #4607

I cannot give you an exact EST but looking at the PR, it looks very ready.

[timdeschryver]

Version 19.0.0-beta.0 is now available, keep in mind that there will be breaking changes added in next versions before we publish a release candidate.

[DerekLiang]

It seems that the following line is working anymore after upgrade to 19.0.0-beta.0. I need to add "@ngrx/operators": "19.0.0-beta.0", to file package.json explicitly.

import { concatLatestFrom } from '@ngrx/operators';

[timdeschryver]

@DerekLiang since NgRx 18 you should be required to install @ngrx/operators.
When you upgrade NgRx , you should update all packages.

[robertIsaac]

@timdeschryver if we are not using anything from @ngrx/operators is it still required?
I don't see @ngrx/store is marking it as a peer deps in https://github.com/ngrx/platform/blob/main/modules/store/package.json so I guess it's optional if I want to use an operator from there

[timdeschryver]

@robertIsaac it's not required if you're not using one of the following operators: tapResponse, mapResponse, concatLatestFrom.

[acampon-sw]

Hi Guys, Is there an estimate when we have a stable release for ngrx-19 ? Just because I need to know if im starting a project using Angular18 or 19

[kgish]

Hi Guys, Is there an estimate when we have a stable release for ngrx-19 ? Just because I need to know if im starting a project using Angular18 or 19

Same with me. Would sure hate to have to wait very long, because I am eager to migrate our application to Angular v19 soon, but am blocked by NgRx.

[marc-wilson]

Joining the blocked by ngrx club. When we can we expect a fix?

[daiscog]

@timdeschryver it might help reduce the amount of impatient comments that recur every six months if the @ngrx packages weren't so restrictive in their peerDependencies. As you state, "NgRx v18 still works with Angular v19" - so why not declare that formally with "@angular/core": "18 || 19" in the peer dependencies going forward, just like you do with rxjs?

I appreciate the desire to keep in-step with major versioning of Angular for clarity, but that can still apply to the lowermost major version of Angular. Given Angular's breaking change policy, you can be reasonable confident that your packages will work with the current and next majors of Angular as long as they do not consume any deprecated APIs from @angular packages.

Of course, nobody is truly blocked by this; it's not like people need Angular 19 before they can go to production. And even for those who want to bump ASAP, it's still possible to use package.json overrides to work around the declared peerDependencies if they really feel they can't wait. But this isn't really a well-known thing, and I can understand some people's reluctance to do so. So maybe being forward-compatible with the peerDependencies would help reduce the pressure for you guys every major release?

[SteffenLm]

@daiscog Look at the first post from @rainerhahnekamp They can't introduce a breaking change if they increase the range. I don't see any reason to stress the Team. They do an amazing job. Migrating ONE Major Angular/NGRX Version a month earlier or not is not important. Wait or contribute. There's nothing in between.

[rainerhahnekamp]

@daiscog We released the RC last week. We need to wait a few days for early-adopter responses before we can punch out the final one. So...stand by

[markostanimirovic]

NgRx v19.0 has been released. 🤝

[daiscog]

@rainerhahnekamp @SteffenLm To be clear, I wasn't complaining about the wait, and appreciate the effort that needs to go into maintaining Open Source projects like this. I'm totally fine with waiting and said myself "nobody is truly blocked by this".

I was just suggesting that by having the peer dependencies of, for example NgRx 18 state it works fine with Angular 18 & 19 (which as Tim said in the original post we know it does) then you might find you get fewer nagging comments from people who are impatient. (@SteffenLm This would have no effect on the ability to introduce breaking changes in NgRx 19 at all, at which point we'd simply bump the peer deps to just Angular 19 alone.)

[rainerhahnekamp]

All good @daiscog, we're all friends here 🙏

[krstev1994]

@rainerhahnekamp Is there any documentation how to use ngrx signal store v19 because pathState is not working any more?

[brandonroberts]

@krstev1994 the docs are updated to v19. If something's not working as expected, file a new issue with a reproduction.

https://ngrx.io

[DynamiteTom]

Angular 19 Radio buttons are broken with an important but subtle bug

This could break millions of applications without the authors realizing the problem
as the console.log or alert says everything is fine!

They always return one value - even though when you check with console.log - everything looks fine and
the log returns the correct value - But when you pass this value to a if then else or ternary operator
you always get the same value no matter which button is clicked!

I had 2 radio buttons returning 1 and 0 and for 5 years it worked fine on my application
But with Angular 19 - it always now returns 0 - no matter if I click the 1 or not

You can prove I'm right by setting the radio button value locally - see below

checkRB(rbValue : number){

// rbValue = 1; // this will prove the ternary operator is working fine

console.log('rbValue is ', rbValue); // this shows the correct value from the radio button

let color = (rbValue === 1)? 'Black' : 'White'; // always returns White

I thought at first the ternary operator was broken in Angular 19 but it and the if then else statements are fine

I had to change my radio button code to fix the bug