Angular CLI jenseits von ng serve: Generatoren, Ziele, Cache und Build-Statistiken

Die meisten Angular-Entwickler vertrauen früh auf vier Befehle – ng serve, ng build, ng generate und ng test – und schauen nicht weiter. Das funktioniert für kleine Anwendungen, doch je größer das Arbeitsumfeld wird, desto mehr Zeit verbringt man mit dem Manuell-Erstellen von Vorlagen, der Suche nach Versionen, der Schätzung der Bundle-Größe sowie dem Umgang mit kaputten Caches. Die CLI bietet bereits Lösungen für die meisten dieser Aufgaben. Dieser Leitfaden zeigt die Optionen auf, die man sich aneignen sollte, erklärt, wann jede davon hilft, und endet mit einem kompakten täglichen Arbeitsablauf, den man direkt übernehmen kann.

Falls Sie sich noch in der Phase des Erstellens des Arbeitsumfelds befinden, behandelt die Anleitung zu der Einrichtung eines modernen Angular-Projekts diesen Teil; alles Weitere setzt voraus, dass bereits ein Projekt existiert.

Mehr aus ng generate herausholen

Der Generator ist der Befehl, den jeder in seiner vollständigen Form kennt:

ng generate component user-profile

Jeder Generator hat einen kurzen Alias – daher wird generate zu g und component zu c:

ng g c user-profile

Die eigentlichen Einsparungen ergeben sich durch die Flags. Wenn ein kleiner Präsentationskomponente keine Spezifikationsdatei erfordert, verhindert --skip-tests, dass die CLI eine solche erstellt:

ng g c user-profile --skip-tests

Standardmäßig landet jede Komponente in ihrem eigenen Ordner. --flat schreibt die Dateien hingegen direkt in den aktuellen Ordner – was für kleine Komponenten geeignet ist, die neben ihrem Elternordner liegen:

ng g c user-profile --flat

Flags können kombiniert werden, sodass man beides gleichzeitig anfordern kann:

ng g c user-profile --flat --skip-tests

Die gleichen Optionen gelten für Services, Direktiven, Pipes, Guards sowie die anderen Schemata. Wenn man den Generator das Erstellen der Dateien überlässt, bleibt die Benennung und Struktur im gesamten Team konsistent. Fügen Sie --dry-run hinzu, um einen Vorschau zu erhalten, was ein Schema ohne tatsächliches Erstellen erzeugen würde.

Fragen Sie die CLI statt im Internet zu suchen

Der schnellste Weg, herauszufinden, was ein Generator kann, ist, ihn direkt zu fragen. Dadurch werden alle verfügbaren Schemata aufgelistet:

ng generate --help

Der Alias funktioniert auf dieselbe Weise:

ng g --help

Durch Hinzufügen von --help nach einem bestimmten Schema werden alle Optionen zusammen mit kurzen Beschreibungen ausgegeben:

ng g component --help

Die Optionen ändern sich zwischen den Versionen, und Forenantworten beschreiben oft ältere Flags; die Hilfemitteilung entspricht stets der in Ihrem Projekt installierten CLI.

Einstellungen mit ng config lesen und ändern

Die Konfiguration des Arbeitsbereichs befindet sich in angular.json, und es ist verlockend, diese Datei direkt zu bearbeiten. Die CLI bietet einen Befehl zum Lesen und Schreiben dieser Werte:

ng config

Wenn dieser Befehl allein aufgerufen wird, gibt er die Konfiguration aus, sodass man sehen kann, was eingestellt ist:

ng config

Man kann auch einen JSON-Pfad übergeben, um einen Wert zu lesen, oder einen Pfad gefolgt von einem Wert, um ihn zu setzen – beispielsweise, um eine CLI-Option für den gesamten Arbeitsbereich zu ändern. In Skripten ist ein wiederholbarer Aufruf von ng config besser als brüchige manuelle JSON-Änderungen: Wenn die CLI eine Datei verwaltet, sollte man sie zur Änderung verwenden.

Ihre Umgebung mit der ng-Version melden

Wenn etwas nicht funktioniert, sind genaue Versionen wichtig. Anstatt package.json zu öffnen und die Informationen zusammenzusetzen, führen Sie Folgendes aus:

ng version

oder die Kurzform davon:

ng v

Die Ausgabe listet in einem Block die Angular CLI-Version, die installierten Angular-Pakete, Node.js, den Paketmanager sowie das Betriebssystem auf. Genau das benötigen ein Teamkollege oder der Wartungsperson, wenn man um Hilfe bittet. Ein Bericht, der lediglich angibt, dass das Projekt nicht mehr funktioniert, liefert ihnen keine Anhaltspunkte, während das Einfügen der Ausgabe des folgenden Befehls bereits ihre ersten fünf Fragen beantwortet:

ng version

Der Produktions-Bundle messen anstelle zu raten

Dieses Build-Flag verdient weitaus häufigere Verwendung, als es derzeit der Fall ist:

ng build --stats-json

Es wird eine Statistikdatei geschrieben, die beschreibt, was in jeden Ausgabeblock eingeflossen ist. Liefern Sie diese Datei an einen Bundle-Analysator, und Sie erhalten eine visuelle Aufschlüsselung darüber, woher die Bytes stammen. Beachten Sie, dass sich das Dateiformat nach dem Builder richtet: Ältere builds basierend auf webpack erzeugen webpack-Statistiken, während der neuere, auf esbuild basierende Anwendungsbuilder esbuild-Metadaten ausgibt. Wählen Sie daher einen Analysator, der die Ausgabe Ihres Builders versteht, und prüfen Sie die aktuellen Angular-Dokumente für Ihre Version.

Häufige Ursachen dafür, dass eine Anwendung langsam wirkt, sind:

• eine zu große Bibliothek von Drittanbietern
• Chunks, die viel größer sind als erwartet
• dieselbe Abhängigkeit, die mehrfach mitgebündelt wurde
• mehrere ressourcenintensive Komponenten, die bei der initialen Ladenzeit mitgeladen werden
• verspätet geladene Funktionen, die am Ende größer ausfallen als geplant

Nichts davon ist allein aus der Quelle sichtbar. Der Vergleich der Statistiken vor und nach einem Upgrade einer Abhängigkeit ist eine einfache Methode, um Rückschritte aufzudecken.

Löschen Sie den Build-Cache, bevor Sie alles neu installieren

Die CLI speichert einen dauerhaften Festplattencache, damit wiederholte Builds schneller ablaufen. Der Befehl ng cache verwaltet diesen Cache; ng cache info zeigt an, wo der Cache gespeichert ist und ob er aktiviert ist:

ng cache

Wenn die Builds seltsam zu funktionieren beginnen, ist das Löschen dieses Caches oft die richtige Maßnahme:

ng cache clean

Veraltete Cache-Einträge tauchen oft nach einem Änderung in den Abhängigkeiten, einem Angular-Upgrade oder dem Wechsel zwischen Branchen mit unterschiedlichen Paketversionen auf. Das Löschen des Caches dauert nur Sekunden, also versuchen Sie es lieber, anstatt den zeitaufwändigen Weg über das Löschen von node_modules und Neuinstallation einzuschlagen.

Linten Sie lokal und in CI

Falls Ihr Projekt einen Linter konfiguriert hat, führen Sie ihn mit folgendem Befehl aus:

ng lint

Neueer Angular-Versionen liefern standardmäßig keinen Linter mit, sodass ng lint nur dann funktioniert, nachdem man einen hinzugefügt hat – in der Regel über die Angular-ESLint-Integration. Sobald er konfiguriert ist, erkennt er Probleme, bevor ein Prüfer Folgendes tun muss:

• unverwendete Variablen und Importe
• Inkonsistenzen in der Formatierung
• Mögliche Fehler
• Nicht empfohlene Muster
• Allgemeine Probleme bei der Codequalität

Durch Ausführung derselben Anweisung im CI-Pipeline wird fehlerhafter Code bereits vor Erreichen der Hauptbranche markiert, und niemand muss sich daran erinnern müssen, sie auszuführen.

Tests in der Automatisierung einmal ausführen

Lokal bleiben Testausführungen in der Regel im Überwachungsmodus und werden bei jeder Speicherung erneut gestartet:

ng test

Eine CI-Aufgabe hat keinen Nutzen von einem Prozess, der auf Dateiveränderungen wartet. Durch Deaktivierung des Überwachungsmodus wird die Anweisung die Testsuite einmal ausführen und anschließend beenden:

ng test --watch=false

Der Abbruchcode gibt anschließend an, ob die Tests bestanden haben – das ist es, was der Pipeline verwendet, um den Job als grün oder rot zu kennzeichnen. Eine in Überwachungsmodus befindliche Pipeline hängt einfach fest, bis eine Zeitüberschreitung eintritt. Lokale Entwicklung und CI haben unterschiedliche Anforderungen, und eine einzige Befehlszeile muss nicht beide bedienen.

Ein einzelnes Projekt in einer mehrprojektigen Arbeitsumgebung auswählen

Größere Angular-Repositorys enthalten oft mehrere Anwendungen und Bibliotheken in derselben Arbeitsumgebung. Die meisten Befehle akzeptieren einen Projektnamen, sodass Sie nur eine Anwendung kompilieren können:

ng build my-app

oder nur einen Test durchführen:

ng test my-app

In einer arbeitsspeicherbasierten Arbeitsumgebung wird dies zur Routine:

ng build admin
ng build customer
ng test shared-ui

Die Arbeit an der gemeinsamen UI-Bibliothek sollte nicht bedeuten, dass jede Anwendung neu kompiliert werden muss; durch gezielte Befehle bleiben Feedbackschleifen kurz.

Jeden Architekturziel mit ng run aufrufen

Hinter den vertrauten Befehlen verbirgt sich ein allgemeinerer Befehl, den nur wenige Entwickler direkt verwenden:

ng run

Er führt ein benanntes Architekturziel aus der Arbeitsplatzkonfiguration aus, wobei die Form project:target verwendet wird, optional ergänzt durch einen Konfigurationsnamen:

ng run my-app:build

Die Standardbefehle sind eigentlich Abkürzungen für gängige Ziele. ng run wird nützlich, sobald ein Arbeitsplatz benutzerdefinierte Ziele definiert – beispielsweise einen Builder, der Code generiert, eine Vorschau bereitstellt oder eine spezialisierte Testumgebung ausführt. Man kann es sich als „Führe genau dieses Ziel dieses Projekts aus“ vorstellen, ohne weitere Schlussfolgerungen.

Dokumentation über die Terminal öffnen

Wenn Sie eine API schnell überprüfen müssen, kann die CLI die Suche für Sie starten:

ng doc

Geben Sie ein Schlüsselwort ein, und die CLI sucht es in der offiziellen Angular-Dokumentation nach:

ng doc signals

Beachten Sie, dass die Ergebnisse in Ihrem Browser angezeigt werden und nicht im Terminal ausgegeben, sodass es sich um einen Shortcut zur richtigen Seite handelt und nicht um eine Offline-Referenz.

Lassen Sie Hilfe die Auswendiglernen ersetzen

Möglicherweise ist diese Anweisung die nützlichste von allen:

ng help

Es listet alle Befehle der obersten Ebene auf. Für die Optionen eines bestimmten Befehls fügen Sie --help hinzu:

ng build --help

Das Gleiche gilt für Generatoren, bis hin zu einem einzelnen Schema:

ng generate service --help

Niemand muss sich alle Flags auswendig merken. Produktive Entwickler sind selten diejenigen, die sich alles merken; sie sind vielmehr diejenigen, die wissen, wo sie suchen müssen, sobald sie etwas vergessen.

Eine tägliche Arbeitsroutine, die alles zusammenführt

Eine praktische Routine könnte wie folgt aussehen. Starten Sie den Entwicklungsserver:

ng serve

Beim Erstellen von Funktionen generieren Sie das Gewünschte mit den richtigen Flags:

ng g c profile --skip-tests

Vor dem Commit prüfen Sie den Code mit Lint-Tools und führen Sie die Tests einmal aus:

ng lint
ng test --watch=false

Für eine Produktionskompilierung verwenden Sie explizit die Produktionskonfiguration:

ng build --configuration production

Wenn die Größe des Bundles von Bedeutung ist, generieren Sie Statistiken:

ng build --stats-json

Wenn die Kompilierung unerwartet reagiert, leeren Sie zunächst den Cache:

ng cache clean

Und immer dann, wenn Ihnen eine Option entfällt, fragen Sie die eigene Befehlszeile:

ng <command> --help

Zusammenfassung

Die Angular CLI ist eine Produktivitätsschicht für den gesamten Entwicklungsprozess, und die größten Vorteile ergeben sich aus einigen wenigen Optionen, die wiederholende Arbeiten entfernen:

• Generieren Sie Code mit Flags anstelle von manuellem Schreiben von Boilerplate
• Richten Sie Befehle in mehrprojektigen Arbeitsumgebungen auf ein einzelnes Projekt aus

Messung von Paketen mit Statistiken anstelle von Schätzungen zur Leistung

Löschen Sie den Cache, bevor Sie zu einem vollständigen Neustart greifen

Führen Sie Tests ohne Überwachungsmodus in CI durch und prüfen Sie bei jeder Änderung die Syntax

Berufen Sie sich auf --help, das immer zur installierten Version passt

Nächstes Mal, wenn Sie ein Terminal in einem Angular-Projekt öffnen, denken Sie daran, dass hinter ng viel mehr steckt als das hier:

ng serve