- read

Upgrading an enterprise app to Angular 16

Jose I Santa Cruz G 7

Angular 16 release — ngcc no more

I'm absolutely bought by all the new Angular v16 features, starting by signals, and well, everything else. And I just couldn’t resist the urge to upgrade one of the company’s apps just to see how hard it could be.

There’s the leading edge and the bleeding edge. You may choose to lead or to bleed, it’s your choice of pain.

Everybody (almost) is talking about Angular 16. Hype or not, most likely you've already read about:

  • granular reactivity (signals)
  • required @Inputs()
  • query, data and resolver params as Inputs()
  • destroyable suscriptions
  • inputs on ngComponentOutlets
  • Vite for development server
  • SSR hydration
  • signals, signals, signals…

you've got the point.

Where’s the catch for an existing enterprise application?

Only Ivy is supported.

And the pain?

Legacy libraries…

Who’s to blame?

Yikes! hard question. But it is a mix of responsibilities.

  1. Angular library developers. Just to name a few libraries: custom-validators, text-mask, old versions for formly, ng-bootstrap, nebular (more on old versions soon). None are properly upgraded to use a latest or at least supported Angular version. Some are plainly abandoned. Ivy not supported.
  2. Company developers. Ok, I know it’s not simple to keep all your dependencies up to date, more difficult to achieve if “the code is already working, no real need to update”. Already went through this pain when updating to Angular 15; some heavy and badly customized Angular Material components are still making noise in our code (don’t know how much time will the LegacyMaterialXXX modules stand).
  3. Angular team(?) We can argue on this one, but on MHO the question should be “is Angular 16 meant to upgrade existing enterprise apps or just for creating new apps from zero?”.
    This comment ain’t pretty (from issue: Alternate way to compile non-ivy libraries after removal of ngcc in v16 #24797):

I know, major versions are expected to break things, harsh truth; but this kind of answer is like if the Angular team was saying “I care about all of you: Me, myself and I”, (the kind of opinions in the open source community you don’t like to read/hear); plenty of time for a corporate app is not measured the same way for everyone, but that's your problem not ours…

I mean, a considerably big code base, that drags some (many) “already work this way” components that rely on abandoned libraries, is not so simple to upgrade. It can also mean a whole new project (developer time), and what for? so angular ≤ 17 breaks everything again? hard decision. “Maybe we should have stayed with Angular 9…

Image from https://cilected.com/bootstrap-4-vs-bootstrap-5/

If anyone struggled with the Bootstrap (not ng-bootstrap) version 4 to 5 upgrade you can have a slight idea, most things still worked and looked almost (almost) the same, but at the same time, many things that used to work (or look nice on the Bootstrap standards) ended broken.

Imagine a code base that heavily relies on the old Bootstrap styles, heavy customized and poorly developed Angular Material components, many unmaintained directives and libraries to handle from animations to form validations.
Upgrading to any framework version which promotes a better way for ehm…, everything (?) won’t be an easy task.

Old versions, why?

When you are working on a project you may face the following decision:

Do we have to use an UI framework? or do we stick to hand coded ad-hok components styled using plain CSS?

Choose your poison:

Whatever your choice is, you will probably keep it until the end of times. If the enterprise application grows larger, the effort on keeping the UI framework library versions up to date will become more and more expensive (developer time is expensive). Same happens when your team has to choose any other tool for solving a recurrent problem (eg using a mask for text inputs). If the library's authors do not keep their libraries updated or even if they do, but developers in our project do not upgrade from older versions, there WILL come a time when things will stop working.

Upgrading pain is unavoidable.

I insisted on my attempt of upgrading. How hard can it be?
So just in order to get a running app without compilation errors (ignoring visual breakages), I updated most of the libraries that could be updated. Tried again, and again, and again… rinse and repeat…

The main problem is that you can have many outdated, abandoned, or unmaintained libraries where the underlying code that does the work, STILL WORK! The only problem is that the Angular dependencies n these libraries are obsolete.

For eg. one of this kind of libraries in the project I'm working on is text-mask , a library from 5 years ago. And even though it's an unmantained library, the code still works. Migrating to another library would require developer's time + time for testing everything still works as before.
Copied and pasted the main library code as if it was an internal library in the project, made a couple of adjustments, et voila, it still works, the code is not wrong, the library dependencies are “wrong”. Nevertheless, if using the original library, Angular 16 throws an error, “The library does not support Ivy”.

So far, there are so many old, obsolete, unmantained, and abandoned dependencies in this project that upgrading may become a whole different project by itself. Stopped trying to upgrade after noticing that there're far to many changes to be done just to get a clean build.

Is it possible to upgrade an enterprise Angular application to Angular 16?

It is possible, but if the application is complex, or if it has lots of, lets say “not yet supported by Angular 16 libraries” it may not be so simple.

Be prepared to start by making many compilation tests in order to determine which libraries need a version upgrade, and which may require some special treatment (such as extracting the working code and building an internal version for that library).

Then, if you manage to get a clean build, you'll probably need to check all visual styles for every component (just in case something is visually broken).

Upgrading is plausible (more than possible), but it won't be a “flawless victory”.

I actually upgraded succesfully an Angular application to Angular 16.
It isn't an enterprise application, it doesn't have any external dependencies other than Tailwind and Angular itself, so it's so simple that upgrading was almost a direct task.

On real enterprise applications, do not expect a happy path, neither a happy ending. Failing in this task has a high chance of happening.

And it's not that I'm not into Angular 16, I really love all the announced features, but upgrading to this just released version WILL BE A PAIN!

Early adopters: Beware!