Christoph Tschui11. Dezember 20234 min read

Angular 16 Release: Was es beim Updaten zu beachten gibt

Bei GARAIO setzen wir für neue Web-Applikationen konsequent auf Angular und sind deshalb immer sehr gespannt auf die neuen Features und Verbesserungen, die mit einem neuen Release kommen. Mit dem Release 16 wurden viele neue Features eingeführt, die die Zukunft des Frameworks prägen. Auf einige dieser Features versuchen wir, mit diesen Blogbeiträgen, etwas näher einzugehen. Dies ist Teil 2 einer fünfteiligen Serie über den Angular 16 Release, welcher am 4. Mai 2023 veröffentlicht wurde.

Teil 2: Was gibt es beim Updaten von bestehenden Applikationen zu beachten?

Grundsätzlich ist das Update auf Angular 16 nichts Anderes, als vorherige Updates. Doch mit Angular 16 kamen einige Änderungen dazu, welche es erfordern, sich Gedanken zu machen, wie man damit umgehen möchte. Zudem muss man sich bewusst sein, dass eingesetzte Bibliotheken allenfalls nicht mehr kompatibel sind, da nur noch für `Ivy` kompilierte Bibliotheken unterstützt werden.

Generelles Vorgehen, beim Updaten von Angular Applikationen

Was man sicher beachten sollte:

Angular Update Guide(s) beachten
- Dynamischer Update Guide, wo man Start und Zielversion angeben kann und eine Checkliste erhält
- Update Guide mit der Liste der Änderungen.
Angular Changelog beachten
Installierte Bibliotheken auf Kompatibilität prüfen
Changelog der Bibliotheken beachten
Schritt für Schritt updaten
- Oft müssen auch Bibliotheken mit --force upgedatet werden, da sie eine feste Abhängigkeit zu Angular haben, bevor dann das eigentliche Angular update gemacht werden kann (ng update @angular/core@16)
Sicherstellen, dass man eine unterstütze Version von Node.js und TypeScript einsetzt.
- Angular 16 unterstützt Node.js Versionen 16 und 18, und TypeScript Version 4.9.3 oder neuer (auch Typescript 5)

Was ist speziell beim Update auf Angular 16

ngcc wurde entfernt

ngcc war dafür zuständig, noch für View Engine kompilierte Bibliotheken in Ivy kompatible Bibliotheken zu kompilieren.

Was ist überhaupt View Engine bzw Ivy und seit wann gibt es Ivy?

Angular hat sich im Laufe der Zeit weiterentwickelt, und eine wesentliche Veränderung war die Einführung von Ivy als neuer Compiler und Renderer, der den vorherigen View Engine ersetzt hat. Ivy wurde in Angular 9 als Standard eingeführt und markierte einen bedeutenden Fortschritt in der Architektur des Frameworks. Im Gegensatz zur View Engine ist Ivy effizienter, da er kleinere Bundle-Grössen und schnellere Kompilierungszeiten bietet. Ivy bringt zudem Vorteile in Bezug auf Tree-Shaking, was bedeutet, dass nur der für die Anwendung relevante Code gebündelt wird, was insgesamt zu einer verbesserten Leistung und einer besseren Entwicklererfahrung führt. Seine Fähigkeit, dynamischere und flexiblere Komponenten zu generieren, macht Ivy zu einer fortschrittlicheren Engine, die den Angular-Entwicklungsprozess optimiert.

Wie stelle ich fest, ob meine Bibliotheken für `Ivy` kompiliert wurden?

Am Anfang vom ng build (je nach Angular Version, hier Angular 14) erscheint eine Meldung mit den konvertierten Bibliotheken:

Processing legacy "View Engine" libraries:

- angular-split [es2015/esm2015] (https://github.com/bertrandg/angular-split.git)

- ngx-virtual-scroller [main/commonjs] (git+https://github.com/rintoj/ngx-virtual-scroller.git)

- ngrx-forms [es2015/esm2015] (https://github.com/MrWolfZ/ngrx-forms.git)

- ngx-treeview [module/esm5] (git+https://github.com/leovo2708/ngx-treeview.git)

- muuri-angular [es2015/esm2015] (dennisameling/muuri-angular)

Encourage the library authors to publish an Ivy distribution.

Ansonsten gibt es kein uns bekanntes Tool, das einem sagen kann, ob eine Bibliothek für View Engine oder für Ivy kompiliert ist.

Grundsätzlich sollte die Dokumentation der entsprechenden Bibliotheken beigezogen werden.

Was tun, wenn eine Bibliothek, welche ich einsetze, nicht für `View Engine` kompiliert ist?

Folgende Varianten sind in diesem Fall denkbar:

Herausfinden, ob es nicht eine neuere Version gibt, welche für `Ivy` kompiliert ist.
Herausfinden, ob die Bibliothek allenfalls eine Nachfolge-Bibliothek hat, bzw. empfiehlt.
Eine andere Bibliothek finden, welche eine ähnliche Funktionalität bietet.
Im Falle von Open Source, die Bibliothek selber kompilieren.
- Achtung, hier die Lizenz genau beachten.
- Im Optimalfall einen PR für die Bibliothek erstellen, damit Andere von der Arbeit profitieren können.
Code oder Code-Teile in eigenes Projekt übernehmen.
- Auch hier die Lizenz beachten.
Die Funktionalität anders in der bestehenden Applikation umsetzen.

Einsatz neuer Features planen

Update auf Typescript 5 oder auf 4 bleiben?
- Das Updaten auf Version 5 ist etwas aufwändiger, dafür ist man nachher schon bereit für das Update auf Angular 17, wo Typescript 5 vorausgesetzt wird.
Strategie für Nutzung von neuen Features (abhängig von welcher Version man kommt) festlegen (Bsp. Signals / Standalone components / SSR / @Input für Route Parameter)
@Input für Route Parameter hat einige Tücken (nicht mehr sichtbar in den Routes (x.routing.ts), funktioniert nur auf "root" Komponente)

Standalone Components

Standalone Komponenten, Direktiven und Pipes zielen darauf ab, das Schreiben von Applikationen zu vereinfachen, indem sie den Bedarf an NgModules reduzieren.

Bestehende Anwendungen können optional und schrittweise den neuen Standalone Stil übernehmen, ohne Breaking Changes befürchten zu müssen.

Das ist zwar ein Angular 15 Feature, welches aber mit Angular 17 zum Standard wird, wenn neue Komponenten erstellt werden.

Deshalb kann man sich hier gut Gedanken machen, ob man die Applikation oder Teile davon bereits umstellen möchte.

Es ist ein Migrations-Tool für den Wechsel von modul-basierten Applikationen auf Standalone Applikationen vorhanden.

Die Dokumentation findet sich hier: angular.io Standalone Migration

Die Migration kann dabei in mehreren Stufen ausgeführt werden.

Diese sind:

Stufe 1: Alle Komponenten, Direktiven und Pipes werden in die Standalone Variante umgewandelt.
Stufe 2: Jetzt ungenutzte Module werden entfernt.
Stufe 3: Das Bootstrapping der Applikation wird angepasst.

Fazit

Eigentlich ist es keine Hexerei seine Applikation auf Angular 16 zu migrieren. Der schwierigste Teil dabei dürfte sicherlich das Ersetzen von Libraries durch den Wegfall von ngcc sein.

Der andere wichtige Teil betrifft vor allem den Umgang mit den neuen Features.

Lesestoff

Was ist ngcc? (Englisch)

Angular Architects Beitrag über das Update (Englisch)