Running @ngrx/signals v19 and Angular v18

[jesse-beckton-alight]

I started using @ngrx/signals v19 in an angular app running on angular v18. So far no issues but I'm wondering what my risks are with this set up. Is it safe to keep using it or should I rip it out? I have some complex implementations that the ngrx/signals library has made major improvements on. I don't really want to revert back but this set up may end up in production. I'm hoping for an angular upgrade before then, but that decision is not on me.

[jdegand]

Peer dependency mismatches and upgrading could become a problem. Using --legacy-peer-deps can help when installing new packages or upgrading existing ones. This could complicate CI/CD and cause issues there as well. You can use the angular upgrade guide to work through the necessary changes.

[jesse-beckton-alight]

I don't plan on upgrading the ngrx libs until we get an angular upgrade. Our project already requires --legacy-peer-deps or --force in order to install current packages, it's kind of a mess. I'm mainly concerned about runtime issues.

[rainerhahnekamp]

We didn't introduce any new Signal types in NgRx 19. There could be some issues with the types, but if you haven't encountered them by now, it should work.

The only thing that you need to prepare for: effect changed a little bit its behavior/schedule in Angular 19. So if you upgrade to Angular (not NgRx) 19, you could have certain issues if you use the effect to access the DOM.

[jesse-beckton-alight]

Good to know. As soon as we upgrade Angular I'll upgrade the ngrx/signals lib accordingly. We are only using the angular effect for watching state changes from the store, nothing having to do with the template or DOM. Just having the reactive state and composability has been a great benefit, so I won't get too crazy with it given the potential version conflicts.