Keeping up to date with Angular. Should you update?
It’s a common problem for projects to use stale versions of packages when they go to production. Everyone is focused on delivering new features, fixing bugs, perhaps if you are lucky enough — even tending to some tech debt. Then, one day it turns out that you’ve been using the same version of packages for years. You discover a bug or a very important feature that requires you to update, but you cannot. There is simply too many breaking changes, and tending to those would require days if not weeks with a lot of possible issues and regressions around that. Could it have been avoided?
A small example from the real life. I once entered a project that used Angular v8. It was 2021. We needed to upgrade. Then, we discovered that upgrading to Angular v9 was impossible, because one library that was used hadn’t been updating for the last 3 years. It had been using long deprecated APIs that got removed from Angular v9. We were in luck. The library wasn’t used in too many places, so we managed to replace it with a modern alternative. This, from one side, enabled us to continue upgrading Angular, from another — it made it evident that if the project had gone through some regular updates this would have been spotted way earlier.
Angular releases
Angular release principles are one of the things that I admire the most in the framework. They release major versions twice a year, and despite that don’t bring breaking changes usually. Also, they give you a nice CLI to update effortlessly, while also running schematics (do you know any other framework that would update your codebase for you?).
You simply run ng update @angular/cli @angular/core and in 95% of the cases you are done. Sometimes, you might need to update other libraries that specify Angular as their peer dependency. Even more rare, you would have to go through your repo manually to perform changes that couldn’t happen automatically.
I’ve been working with Angular since v4 and have been keeping my projects up to date wherever possible. The only problem with updates I remember is migration from Angular v8 to v9 where a lot of breaking changes happened, and a new Ivy engine was introduced by default. All the other updates have been a breeze. Just ng update and commit. Build a prod version of the project, verify it passes. Run tests. Check a few pages in the browser. Easy peasy.
New features
One of the things that keep some developers from updating to newest version of Angular is new features that are in the preview. Here, we need to remind ourselves that you are not obliged to use features that are in developers preview. If you don’t use them you get a fully stable version of Angular that has been tested on tons of projects inside Google before the release to ensure smoothness and readiness.
You are not forced to use the features that are not in the preview anymore either. E.g. standalone components, directives, pipes have been there for a while and you still can develop with the good old SharedModule. However, you will be missing some of the cool stuff.
For example, in Angular v17 we received the new control flow (in developers preview) which supports deferrable views. Those enable us to declaratively mark a piece of HTML as a “deferred view”. This will create a separate lazy-loaded chunk. You can specify conditions (a whole lot of them) to determine when the block should be loaded. However, there is a gotcha. It’s supported for standalone API only. So, if you haven’t upgraded — you won’t be able to harvest this fruit.
Another example is signals. They are stable as of the fall 2023. With them becoming stable, we also received a nice bonus just before the release of Angular v17. If your view requires an update because its signal was changed and you haven’t called markForCheck() or used async pipe — only this component will be checked during the change detection (no more checking parents if it’s only your component that has changed its state). This is only when the signal value is updated and it’s read from the template (if you listen for an event, it will trigger the “old” change detection which marks all parents as dirty because it’s the event that drives the thing, not data change).
Now, we just received signal inputs and model inputs. They are in the preview, but I think they won’t change much from the API perspective. They already can let you make the life easier to run some code on inputs change in an effect or derive state from the input. No more ngOnChanges or setters.
Breaking changes
As it was mentioned earlier there are rarely breaking changes because the Angular team understands how difficult it can be to migrate the codebase. Features that get deprecated aren’t removed for a few versions and usually target some rather rare cases. I can’t recall any deprecations in my projects.
When those occur, the Angular team usually provides us with schematics to migrate the codebase. Which is again a very enabling thing for updates. Usually, if you see a library that supports some Angular higher than v9 it’s usually compatible even with the latest version of Angular despite the NPMs complaints.
Summarising the above, if you have spare 10–20 mins you should always update. Doing so makes you more confident your project doesn’t become a legacy one as fast. Migrating to the newer solutions (e.g. standalone API) and tending to the tech debt will also make the situation better and fresher. You’ll be getting an improved DX, improved performance while most of the job is just run a command and wait for it to end.
Spending a few minutes to update twice a year will save you a lot of time and efforts that you might need if you waited for a few years and then suddenly decided to update. Don’t wait so long that it becomes easier to rewrite the project with a new technology.
