Angular CLI au-delà de ng serve : générateurs, cibles, cache et statistiques de compilation

La plupart des développeurs Angular s’en tiennent dès le début à quatre commandes, ng serve, ng build, ng generate et ng test, sans jamais chercher plus loin. Cela convient pour une petite application, mais à mesure que l’espace de travail s’agrandit, le temps consacré à écrire manuellement du code générique, à rechercher des numéros de version, à estimer la taille des fichiers compilés et à gérer des caches défectueux augmente considérablement. La CLI dispose déjà de solutions pour la plupart de ces tâches. Ce guide présente les options qui méritent d’être intégrées à la routine quotidienne, explique quand chacune est utile, et se termine par un flux de travail quotidien compact que vous pouvez adopter tel quel.

Si vous êtes encore à l’étape de création de l’espace de travail lui-même, la démarche décrite dans la mise en place d’un projet Angular moderne couvre cette partie ; tout ce qui suit suppose qu’un projet existe déjà.

Tirer le meilleur parti de ng generate

Le générateur est la commande que tout le monde connaît sous sa forme complète :

ng generate component user-profile

Chaque générateur dispose d’un alias abrégé, de sorte que generate devient g et component devient c:

ng g c user-profile

Les vraies économies proviennent des flags. Lorsqu’un petit composant de présentation ne nécessite pas de fichier de spécification, --skip-tests empêche la CLI d’en créer un :

ng g c user-profile --skip-tests

Par défaut, chaque composant est placé dans son propre dossier. --flat écrit directement les fichiers dans le répertoire courant, ce qui convient aux petits composants situés à côté de leur parent :

ng g c user-profile --flat

Les flags peuvent être combinés, vous permettant de les demander tous en même temps :

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

Les mêmes options s’appliquent aux services, directives, pipes, gardes et aux autres schémas. Permettre au générateur de créer des fichiers assure une cohérence dans la nomenclature et l’organisation au sein de l’équipe. Ajoutez --dry-run pour prévisualiser ce que créerait un schéma sans écrire quoi que ce soit.

Demandez à la CLI plutôt que de chercher sur le web

Le moyen le plus rapide de découvrir ce que peut faire un générateur est de lui poser des questions. Cela affiche tous les schémas disponibles :

ng generate --help

L’alias fonctionne de la même manière :

ng g --help

En ajoutant --help après un schéma spécifique, toutes ses options accompagnées de descriptions courtes sont affichées :

ng g component --help

Les options changent d’une version à l’autre, et les réponses sur les forums décrivent souvent des paramètres anciens ; la sortie d’aide correspond toujours à la CLI installée dans votre projet.

Lire et modifier les paramètres avec ng config

La configuration de l’espace de travail se trouve dans angular.json, et il est tentant d’éditer ce fichier directement. La CLI propose une commande pour lire et écrire ces valeurs :

ng config

Lorsqu’elle est exécutée seule, elle affiche la configuration afin que vous puissiez voir ce qui a été défini :

ng config

Vous pouvez également passer un chemin JSON pour lire une valeur, ou un chemin suivi d’une valeur pour la modifier, par exemple pour changer une option de CLI pour tout l’espace de travail. Dans les scripts, un appel répétable à ng config est préférable aux modifications manuelles fragiles du JSON : lorsque la CLI gère un fichier, utilisez-la pour le modifier.

Rapportez votre environnement avec la version ng

Lorsqu’un problème survient, les versions exactes sont importantes. Plutôt que d’ouvrir package.json et de rassembler les informations manuellement, exécutez :

ng version

ou sa forme abrégée :

ng v

La sortie affiche en un seul bloc la version d’Angular CLI, les paquets Angular installés, Node.js, le gestionnaire de paquets ainsi que le système d’exploitation. C’est exactement ce dont a besoin un collègue ou un mainteneur lorsque l’on demande de l’aide. Un rapport qui se contente d’indiquer que le projet ne fonctionne plus ne leur fournit aucune piste, tandis que la copie de la sortie de la commande suivante répond d’emblée à leurs cinq premières questions :

ng version

Mesurer le bundle de production plutôt que de deviner

Cette flag de compilation mériterait d’être utilisée bien plus souvent qu’elle ne l’est actuellement :

ng build --stats-json

Celui-ci écrit un fichier de statistiques décrivant ce qui a été inclus dans chaque chunk de sortie. En alimentant ce fichier à un analyseur de bundles, on obtient une représentation visuelle de l’origine des octets. Notez que le format du fichier dépend du générateur : les builds anciens basés sur webpack génèrent des statistiques webpack, tandis que le générateur d’applications plus récent basé sur esbuild émet des métadonnées esbuild ; choisissez donc un analyseur capable de comprendre la sortie de votre générateur et consultez la documentation actuelle d’Angular pour votre version.

Les constatations typiques lorsqu’une application semble lente incluent :

• une bibliothèque tierce trop volumineuse
• des chunks bien plus gros que prévu
• la même dépendance incluse plusieurs fois
• quelques composants lourds chargés lors du chargement initial
• des fonctionnalités chargées de manière différée qui s’avèrent plus volumineuses que prévu

Aucun de ces éléments n’est visible uniquement à partir du code source. Comparer les statistiques avant et après une mise à niveau de dépendance est un moyen simple pour détecter les régressions.

Vider le cache de compilation avant de tout réinstaller

La CLI conserve un cache en mémoire persistante afin que les compilations répétées soient plus rapides. La commande ng cache le gère ; ng cache info indique l’emplacement du cache et son état d’activation :

ng cache

Lorsque les compilations commencent à se comporter de manière anormale, vider ce cache est souvent la solution :

ng cache clean

Des entrées de cache obsolètes apparaissent souvent après un changement de dépendance, une mise à niveau d’Angular ou un passage entre des branches ayant des versions de paquets différentes. Vider le cache ne prend que quelques secondes, alors essayez-le avant de recourir à la méthode plus lente qui consiste à supprimer node_modules et à réinstaller.

Vérifier la qualité du code localement et en CI

Si votre projet dispose d’un outil de vérification de la qualité du code configuré, exécutez-le avec :

ng lint

Les versions récentes d’Angular ne fournissent pas de linter par défaut, donc ng lint ne fonctionne que dopo avoir ajouté un linter, généralement via l’intégration Angular ESLint. Une fois configuré, il détecte les problèmes avant que quiconque n’ait à :

• variables et imports inutilisés
• incohérences de formatage
• bugs potentiels
• patterns déconseillés
• problèmes généraux de qualité du code

Exécuter la même commande dans le pipeline CI permet de signaler les codes problématiques avant qu’ils n’atteignent la branche principale, et personne n’a besoin de se souvenir d’exécuter cette commande.

Exécuter les tests une fois en mode automatique

En local, les exécutions de tests restent généralement en mode surveillance et se réexécutent à chaque sauvegarde :

ng test

Un job CI n’a pas besoin d’un processus qui attend des modifications de fichiers. Désactiver le mode surveillance fait en sorte que la commande exécute la suite une fois puis s’arrête :

ng test --watch=false

Le code de sortie indique alors si les tests ont réussi, ce qui permet au pipeline de marquer le job en vert ou en rouge. Un pipeline en mode surveillance reste bloqué jusqu’à expiration du délai imparti. Le développement local et les tests continus ont des besoins différents, et une seule ligne de commande n’est pas nécessaire pour les deux.

Cibler un seul projet dans un espace de travail multi-projets

Les dépôts Angular plus importants contiennent souvent plusieurs applications et bibliothèques au sein d’un même espace de travail. La plupart des commandes acceptent un nom de projet, ce qui vous permet de compiler uniquement une application :

ng build my-app

ou de tester uniquement une :

ng test my-app

Dans un espace de travail de type monorepo, cela devient une routine :

ng build admin
ng build customer
ng test shared-ui

Travailler sur la bibliothèque UI partagée ne doit pas signifier de devoir recompiler chaque application ; en ciblant précisément les commandes, on réduit la durée des boucles de feedback.

Appeler n’importe quel cible d’architecte avec ng run

Derrière les commandes familières se trouve une commande plus générale que peu de développeurs utilisent directement :

ng run

Elle exécute une cible architecturale nommée issue de la configuration de l’espace de travail, en utilisant le format project:target, éventuellement suivi d’un nom de configuration :

ng run my-app:build

Les commandes standard ne sont en réalité que des raccourcis pour des cibles courantes. ng run devient utile lorsque l’espace de travail définit des cibles personnalisées, comme un outil de génération de code, de déploiement d’une version préliminaire ou d’exécution d’un ensemble de tests spécialisé. Pensez-y comme à « exécuter précisément cette cible de ce projet », sans aucune interprétation supplémentaire.

Ouvrir la documentation depuis le terminal

Lorsque vous avez besoin de vérifier rapidement une API, la CLI peut lancer la recherche à votre place :

ng doc

Transmettez un mot-clé et elle le recherchera dans la documentation officielle d’Angular :

ng doc signals

Notez que les résultats s’ouvrent dans votre navigateur plutôt que d’être affichés dans la terminal, il s’agit donc d’un raccourci vers la bonne page et non d’une référence hors ligne.

Laissez l’aide remplacer la mémorisation

Peut-être que l’habitude la plus utile de toutes est celle-ci :

ng help

Elle liste tous les commandes de niveau supérieur. Pour connaître les options d’une commande spécifique, ajoutez --help :

ng build --help

Cela fonctionne de la même manière pour les générateurs, jusqu’au niveau d’un schéma unique :

ng generate service --help

Nul n’a besoin de mémoriser chaque flag. Les développeurs productifs ne sont pas ceux qui se souviennent de tout ; ce sont ceux qui savent où chercher dès qu’ils oublient.

Un flux de travail quotidien pour tout intégrer

Une routine pratique pourrait ressembler à ceci. Démarrez le serveur de développement :

ng serve

Lors de la création de fonctionnalités, générez ce dont vous avez besoin en utilisant les bons paramètres :

ng g c profile --skip-tests

Avant de faire un commit, exécutez le vérificateur de syntaxe et les tests une fois :

ng lint
ng test --watch=false

Pour une compilation en production, utilisez explicitement la configuration de production :

ng build --configuration production

Lorsque la taille du bundle est un problème, générez des statistiques :

ng build --stats-json

Lorsque la compilation commence à mal se comporter, videz d’abord le cache :

ng cache clean

Et chaque fois qu’une option vous échappe, demandez-lui directement à la commande :

ng <command> --help

En résumé

Angular CLI est une couche de productivité qui entoure tout le cycle de développement, et les plus grands avantages proviennent de quelques options qui éliminent le travail répétitif :

• Générer du code à l’aide de paramètres plutôt que d’écrire manuellement du code générique
• Limiter les commandes à un seul projet dans des espaces de travail multi-projets

Mesurer les ensembles de données avec des statistiques plutôt que de deviner les performances

Vider le cache avant de recourir à une réinstallation complète

Exécuter des tests sans mode observation dans CI et vérifier la syntaxe à chaque modification

Faire confiance à --help, qui correspond toujours à la version installée

Lors de votre prochaine ouverture d’un terminal dans un projet Angular, n’oubliez pas qu’il y a bien plus derrière ng que cela :

ng serve