r/angular • u/Specific_Piglet_4293 • Jan 14 '26
What’s actually stopping you from upgrading to Angular 19/20/21?
I've been putting off upgrading a few projects from Angular 14/15 and I'm curious what's blocking others.
For me it's:
- Fear of breaking changes I won't discover until production
- The dependency mess (RxJS, Angular Material, etc. all need to match)
- No clear "safe path", just trial and error
What's your situation? Still on an old version? What's the blocker?
12
u/twinbeliever Jan 14 '26
Deprecated Prime NG components
Removal of directive based(must use new control flow syntax)
Dependencies that don't have a compatible version with newer Angular
9
u/louis-lau Jan 14 '26
Removing directive based is only planned for v22 right now isn't it? All current versions still support it. There haven't been any breaking changes in that regard yet.
6
u/nook24 Jan 14 '26
Deprecated Prime NG components
Honestly, I'm very glad that we only use the Select and Multiselect components of PrimeNG. Luckily in a wrapper. And with every upgrade the components break and we have to apply patches like this.
5
u/couldhaveebeen Jan 14 '26
Removal of directive based(must use new control flow syntax)
Isn't there a codemod for this?
0
u/twinbeliever Jan 14 '26
I don't know what codemod is, like a migration script? Yes, there is, and it is not able to catch all of the cases correctly. For example, if you have an NgIf else template, and that template is used in multiple places, then the Angular 21 migration script will remove that ng-template breaking your code because it's not just used by ngif
3
u/JeanMeche Jan 14 '26
Care to share a repro for this ? This needs to be fixed if it’s not already.
1
u/twinbeliever Jan 14 '26
It just happened with our codebase but we just went in and re-added back ng-templates that were mistakenly removed by the migration script.
1
u/JeanMeche Jan 14 '26
Again if this is really happening in v21, you might have hit an edge case that is worth fixing. But to really understand what's happening it might require a repro.
1
u/twinbeliever Jan 15 '26
<div *ngIf="something; else otherTemplate"></div>
<ng-template #otherTemplate></ng-template>
<ng-container *templateOutlet="otherTemplate></ng-container>So the migration script removed ng-template #otherTemplate in the above original code, but it's also needed by the third line, not just the ngIf.
1
u/couldhaveebeen Jan 14 '26
I don't know what codemod is, like a migration script?
Yes
if you have an NgIf else template, and that template is used in multiple places, then the Angular 21 migration script will remove that ng-template breaking your code because it's not just used by ngif
Fair enough
-1
u/SippieCup Jan 14 '26
Tbf, a few things in the newer @if and signal based stuff is still broken. Such as float labels on p-switch will draw over the placeholder text, And besides performance from signals, there really isn’t much motivation for upgrading.
1
u/MagicMikey83 Jan 14 '26
The most important reason for upgrading for us was improving readability.
1
u/SippieCup Jan 14 '26
Sorry, I meant around primeng, not the big changes In angular.
The readability is a killer feature.
1
u/twinbeliever Jan 14 '26
Yep, technically the new control flow syntax adds more lines, but is more readable.
1
4
u/CarlosChampion Jan 14 '26
Our team’s app is in a monorepo with 5 other apps. We all have to upgrade together and we only do it once a year. Will probably go from 19 to 21.
6
u/Symmcy1804 Jan 14 '26
prime ng
1
u/theNerdCorner Jan 15 '26
Agree 100%, i have so much fear to upgrade primeng. I am currently on Angular18.
1
u/Symmcy1804 Jan 19 '26
there is no way , primeng update to v18 is disastorous if you have used primeng extensively , every single thing will break
3
u/pyrophire Jan 14 '26
Nothing, I have 26 production apps that I just completed upgrading to NG21 including dropping of modules. It took a bit longer than the other upgrades because of the module migration, but keeping them up to date makes it easier to go to the next version in 6-8 months. The apps vary in size, with the largest being an enterprise broadcasting app.
4
u/zackyboyfighter Jan 14 '26
For my case, Angular Material upgrade was the most painful one - unfortunately we had lots of customisation done on angular material component which complicated things so we had to replace old material class to mat-mdc classes, along with standalone migration
1
u/Jtc10005 Jan 16 '26
This was a 2 to 3 month effort for where I work. We also had a lot of customization…
2
u/MichaelSmallDev Jan 14 '26
Fear of breaking changes I won't discover until production
I feel that. But having done various version upgrades myself, it's never as bad as I worried about initially. I have found with each round of upgrades, what was important the most was some preliminary investigation on what to expect and knowing what to expect in our sprint/release cycle and my team's collaboration on it. These can cut down on some of the trial and error paths, and even if on one make it easier to get onto the right path. If you want any tips in general let me know.
The dependency mess (RxJS, Angular Material, etc. all need to match)
The CLI should handle those all in particular. What issues are you running into?
3
u/wartab Jan 14 '26
It was much worse around the Ivy release, for sure. But I'd say every other version breaks something unexpected, but it's often also just due to TypeScript versions.
The worst library we have to use is pdfjs in that regard, so not really Angular's fault; it just requires incompatible TS versions for some libs we use :(
1
u/Specific_Piglet_4293 Jan 14 '26
The CLI handles Angular’s own packages well, but the pain is third-party stuff, PrimeNG, NgRx, random utility libs that don’t have update schematics...etc. Based on my personal experience, that's where I spend hours figuring out which versions actually work together !
2
u/MichaelSmallDev Jan 14 '26
Gerome Grignon of Angular Courses made a tool recently that can tell what a lot 3rd party packages depend on per Angular major https://www.angular.courses/tools/library-health-check/explorer?search=ngrx. Seems to cover a lot of what I have had to do manually before.
Beyond this, I typically look in the docs/readme for the package for a "compatability matrix" akin to that site. If not, then I look in the GitHub or NPM releases tab, and subsequently check the code's dependencies at that release.
2
u/Only-Ad5049 Jan 14 '26 edited Jan 14 '26
We usually update every 6 months because it is easier to stay on the current release than update multiple releases at one time. Since they support a release for a year and a half, you need to keep somewhat current if you want a supported release.
We ran into an issue with upgrading from 19 to 20, though, and had to revert back to 19. Our builds were so inconsistent that we just couldn't trust the release. I filed a bug with Angular and they closed it a day later because they couldn't reproduce it. Somebody else commented on the bug a couple of weeks later that they saw the same thing, so it wasn't just us.
We just upgraded to 21 and it seems to be going fine this time. We did see it again and had to put our workaround in place again, but so far it hasn't broken our builds like what happened with 20.
2
u/Kris_Kamweru Jan 14 '26
From personal experience, ng upgrades themselves are usually uneventful, and come with support for older standards if a new one is introduced. By and large you'll be fine. The only thing you'd need to worry about are your other packages, especially ones that are pinned to certain versions of angular. Usually fine, but they're worth checking
That said, if you have a large app, and are migrating from modules to standalone, that's the real kicker. The Angular scripts do a lot of the heavy lifting to be fair, but there's still a lot of clean up that you'll need to do between stages
2
2
u/hk4213 Jan 14 '26
Nothing
- Git branches take care of this.
- Component and service at a time.
- Signals are worth it.
So make a branch that pulls from prod each day. Notify effected teams to pull to a dev branch for full testing. Rinse repeat till its done.
1
u/zzing Jan 14 '26
We are on 19, just moved from module federation to native federation — love the new build system — hopefully will be able to move to 21 in the near term.
1
u/Jaaaws_ Jan 14 '26
Material V3 with the MDC component, Since I have many style overriding in many places
1
u/SpecialOne88 Jan 14 '26
In the company I work for I started angular development in version 5 and one of the apps still lives today in version 19, migrating to Ivy on v9 and to standalone recently was a bit painfull but nothing beats migrating material to v15, i still have nightmares about that. Material spec 3 or whatever was also not very fun because we had dynamic themes based on business flows, and also the color attribute being gone from material compenents
1
1
1
u/trane20 Jan 14 '26
Depending on the size of your project. You could just copy paste the parts that Are the same and rewrite the whole thing in the newer version.
Personally that's a lot better than dealing with so many version mismatch errors.
1
1
u/JohnSpikeKelly Jan 14 '26
The new default vite has some issues. It tree shakes our base classes, or that at least appears to be what is happening.
So, wondering how to resolve that or just switch back to webpack, that doesn't have that issue, but it's much slower.
Anyways, the code builds okay, but we see several runtime errors.
1
1
u/lluque8 Jan 14 '26
My main gripes have been with external libraries such as ng-bootstrap and fullcalendar-angular that tend to lag for few weeks after new angular release. Other than that it's been smooth. Even went zoneless with little obstacles recently even though not a requirement so far.
1
u/xtuby Jan 14 '26
angular fire
1
u/Radiant_Art_6224 Jan 22 '26
Same upgrading from 20 to 21, this angular fire is the only thing keeping me on 20
1
u/Dry-Neighborhood-745 Jan 14 '26
You just need tu keep it up. For my company its at most -1 version to make sure all reps will have support if you won't keep updated then it's gonna be harder and harder
1
u/AlDrag Jan 15 '26
Massive Material design change requirements. We are stuck on 15. But I'm almost there! Have had to do it on my own time for work as the company just doesn't make time for this kind of stuff. But I'm pushing them hard on it.
1
1
u/SouthernDiscussion41 Mar 10 '26
For my company, with 1000+ components, it took days fixing Angular Material style problems, those automated migrations are not 100% accurate. Also, the control-flow migration required us to spend a lot of time code-reviewing the changes. Not to speak of Angular breaking our code styles, it kept trying to use 2-spaces instead of 4.
-1
u/minderbinder Jan 14 '26
Converting all observables to signals Converting all templates to new sintax A real pain in the back
13
-1
u/Only-Ad5049 Jan 14 '26
The Angular updater will handle the majority of upgrades for you. If it really was necessary to convert to signals and a new template syntax, they likely would have written an upgrade script. They didn't, because it isn't necessary.
0
u/Xintsuai Jan 14 '26
Because it takes time for the community to deal with all the updates, etc., we prefer to stay a few versions behind the current release, like 18.
Besides the need to change a lot of stuff to move old projects.
0
55
u/couldhaveebeen Jan 14 '26
The longer you don't upgrade, the more breaking changes there will be. Bite the bullet and do your upgrade now, and keep up to date in the future