Chaque équipe d'ingénieurs qui se développe au-delà d'une poignée de projets finit par affronter le même problème : comment garder des dizaines ou des centaines de bases de code compatibles ? Sans normes explicites, chaque nouveau projet devient un flocon de neige – différentes structures de dossiers, différentes versions de dépendance, différentes règles de linte, différentes configurations de test. Le résultat est une charge cognitive accrue, un embarquement plus lent et un cauchemar de maintenance. Nx, le cadre de construction monorepo de Nrwl, a été conçu pour résoudre exactement ce problème. En fournissant un système de générateur, des fichiers de configuration partagés et des mécanismes d'exécution puissants, Nx donne aux équipes les outils pour faire la cohérence directement dans leur workflow.

Le défi de la cohérence à l'échelle

Dans un workflow de développeur typique, la cohérence est obtenue par la documentation et la révision de code. Une équipe écrit une page wiki décrivant la structure de projet préférée, les conventions de nommage pour les bibliothèques et les dépendances requises. De nouveaux projets sont lancés en copieant un vieux projet et en renaissant les fichiers. Ce processus manuel est fragile : quelqu'un saute une étape, utilise une version obsolète d'un fichier de configuration, ou interprète les lignes directrices différemment.

Nx remplace cette approche ad-hoc par une approche programmatique. Au lieu de copier et coller, les développeurs lancent une commande – – et reçoivent un projet qui se conforme à chaque norme définie par l'équipe. Le modèle n'est pas une copie statique; c'est un générateur qui peut intégrer la logique, demander l'entrée de l'utilisateur et câblé la configuration automatiquement. Cela élimine la variabilité qui se déplace avec la configuration manuelle. La cohérence devient le chemin de la moins résistance.

Comment Nx permet la cohérence

Nx obtient une cohérence grâce à trois mécanismes principaux : générateurs, configurations partagées et portes d'exécution. Les générateurs (souvent appelés « schematics » dans la documentation Nx plus ancienne) sont des fonctions qui créent ou modifient des fichiers. Ils sont l'outil principal pour les modèles personnalisés. Les configurations partagées comme , à la racine et propagent les paramètres sur tous les projets.

Générateurs : La Fondation des modèles personnalisés

Un générateur Nx est un fichier TypeScript (ou JavaScript) qui exporte une fonction . Cette fonction reçoit un (une abstraction sur le système de fichiers) et un (les options passées par le développeur). À l'intérieur du générateur, vous pouvez lire, créer, mettre à jour ou supprimer des fichiers. Nx est livré avec un ensemble de générateurs intégrés pour Angular, React, Node et d'autres cadres, mais vous pouvez créer votre propre pour codifier n'importe quel modèle que votre équipe utilise.

Par exemple, imaginez que votre équipe exige que chaque bibliothèque front-end inclue une structure de dossier spécifique : un répertoire pour les exportations de barils, un dossier pour les composants de React, et un dossier pour les tests d'unités. Un générateur personnalisé peut échafauder ce fichier automatiquement. Il peut également ajouter la bibliothèque à un fichier global barils, l'enregistrer dans , et configurer les surcharges ESLint nécessaires. Le développeur ne fournit que le nom de la bibliothèque et un répertoire optionnel; le générateur gère le reste.

Conception de générateurs personnalisés en Nx

La création d'un générateur personnalisé implique quatre étapes de haut niveau : définir l'interface du générateur, mettre en œuvre la logique, l'enregistrer dans ou , et tester contre un arbre de simulation.

Étape 1: Définir le schéma et l'interface

Commencez par décider quels paramètres le générateur acceptera. Les options communes comprennent , , (pour les contraintes de dépendance Nx), et (CSS, SCSS, CSS‐in‐JS). Elles sont définies dans un fichier , qui spécifie également les règles de validation (p. ex., les champs requis, les valeurs par défaut). Le Nx CLI utilise ce schéma pour inciter les utilisateurs ou valider l'entrée.

Étape 2 : Mettre en œuvre la logique du générateur

La fonction générateur reçoit un et les utilitaires validés . Utilisez les utilitaires pour interagir avec l'arbre.

  • generateFiles – copie des fichiers modèles à partir d'un dossier, remplaçant les variables par des valeurs de schéma.
  • addProjectConfiguration – enregistre le nouveau projet dans l'espace de travail.
  • mise à jourJson – modifie , ou .
  • addDependencesToPackageJson – s'assure que les paquets requis sont installés.

Par exemple, un modèle peut contenir pour être remplacé par le nom de la bibliothèque. Vous pouvez également inclure des blocs conditionnels ou des boucles à l'intérieur des modèles si la logique est simple; pour une logique plus complexe, préférez manipuler l'arborescence dans le générateur lui-même.

Étape 3 : Enregistrer le générateur

Les générateurs sont enregistrés dans la section (ou pour les configurations plus anciennes) sous la section . Pour un plugin local, le fichier dans le projet du plugin spécifie quels générateurs sont disponibles et où leur code vit. Une fois enregistré, le générateur devient visible à et peut être découvert par d'autres développeurs via la console CLI ou Nx.

Étape 4: Testez le générateur

Nx fournit un assistant de test, , de . Ecrivez des tests unitaires qui invoquent votre générateur sur un arbre virtuel et affirment la structure de fichier résultante. Testez également les cas de bords : que se passe-t-il si la bibliothèque existe déjà ? Si le répertoire est imbriqué ? Si les options requises sont manquantes ? Un test robuste garantit que le générateur reste fiable au fur et à mesure que l'espace de travail évolue.

Mise en application des normes avec Nx

La création de modèles n'est que la moitié de l'image. Même avec des générateurs parfaits, un développeur peut encore modifier des fichiers après génération de manière à briser les normes. Nx permet d'appliquer automatiquement les normes, sans compter sur l'examen de code humain pour chaque fichier.

Configurations partagées de revêtement et de formatage

Le plugin ESLint de Nx () vous permet de définir des règles à l'échelle de l'espace de travail tout en permettant des dépassements de niveau projet. Par exemple, vous pouvez faire respecter que toutes les bibliothèques doivent suivre une convention de nommage (par exemple, préfixe , , ) en écrivant une règle ESLint personnalisée ou en utilisant . La règle est particulièrement puissante : elle utilise le que vous avez assigné aux projets pendant la génération pour interdire certaines relations de dépendance. Une bibliothèque d'accès aux données, par exemple, ne peut pas importer d'une bibliothèque d'interface utilisateur. Cette contrainte architecturale est imposée au moment de la saisie, pas seulement dans les documents de conception.

Intégration de l'IC aux commandes Nx touchées

Les commandes Nx (, , ) ne fonctionnent que sur des projets qui ont changé, rendant possible une rétroaction rapide même dans de grands monorepos. Configurez votre pipeline CI pour exécuter sur chaque PR. Si un projet échoue à linter, le PR ne peut pas être fusionné. Cette capture ne manque pas de respecter vos règles de linage personnalisée. Combinez-la avec pour faire appliquer le formatage de Prettier. Ensemble, ces vérifications automatisées rendent visible et bloque les normes.

Versions partagées de dépendance

Nx résout les dépendances via un seul à la racine. Cela signifie que tous les projets partagent la même version de, par exemple, React ou Lodash – éliminant la version skew. Pour les monorepos avec différents cadres, vous pouvez toujours utiliser la gestion de la dépendance au niveau de l'espace de travail par ou des espaces de travail, mais Nx fait en sorte qu'aucun projet ne se faufile dans une version conflictuelle via sa propre . Vous pouvez également créer des schémas générateurs personnalisés qui pincent des versions de dépendance spécifiques et les vérifier avec des audits automatisés.

Génération de code comme porte

Dans certains espaces de travail Nx, vous pouvez publier un plugin qui fournit la seule façon autorisée de créer une bibliothèque ou une application. Si un développeur crée manuellement des fichiers, ils risquent de briser le graphique de dépendance et de provoquer un comportement incorrect. En faisant du générateur le seul chemin supporté, vous institutionnalisez les modèles et les normes.

Au-delà de l'échafaudage : Normalisation de l'architecture

Les modèles personnalisés et les règles de linte peuvent imposer non seulement la structure de fichier et le style de code, mais aussi les modèles architecturaux.

Structure du dossier comme contrat

Décidez d'une hiérarchie standard pour votre espace de travail. Un modèle commun pour les monorepos front-end est:

  • apps/ – applications déployables (fonctions web, mobiles, sans serveur)
  • libs/ – bibliothèques partagées, regroupées par domaine ou couche:
    • libs/shared/ui – composants de présentation réutilisables
    • libs/shared/utils – fonctions d'utilité pures
    • libs/caractère/tableau de bord – logique des tableaux de bord
    • libs/caractère/réglages – logique de la fonction de paramètres

Votre générateur personnalisé peut l'appliquer en faisant défaut au répertoire , en demandant une catégorie (p. ex., fonctionnalité, partage, accès aux données) et en plaçant le projet en conséquence. Au fil du temps, chaque développeur internalise la structure car c'est la seule structure que le générateur crée.

Conventions et étiquettes de désignation

Les balises Nx sont des métadonnées attachées à des projets que la règle de limite du module utilise. Par exemple, une bibliothèque marquée peut être autorisée à importer mais non . Définissez votre convention de marquage dans un document de niveau espace de travail, et implémentez-la dans le générateur : quand un développeur crée une nouvelle bibliothèque de type "data-access", le générateur ajoute automatiquement la balise . Ensuite, la règle de lint gère le reste.

Plaque de chaudière commune pour motifs communs

Au lieu de chaque développeur qui met en œuvre un utilitaire de logage différemment, un générateur crée un service de logage cohérent avec la bibliothèque choisie par l'équipe (par exemple Winston, Pino) préconfigurée. Le même principe s'applique aux requêtes GraphQL, aux paramètres REST, aux tranches de gestion d'état, etc. Chaque projet généré devient un modèle des meilleures pratiques de l'équipe.

Intégrer les normes dans votre flux de travail d'équipe

Les solutions techniques ne sont efficaces que si l'équipe les adopte. Voici des étapes pratiques pour déployer des modèles et des normes personnalisés sans accabler vos développeurs.

Début petit: Un générateur, une règle

N'essayez pas de générer tous les types de projets possibles le premier jour. Identifiez le type de projet le plus commun que votre équipe crée – probablement une bibliothèque pour une couche spécifique ou un nouveau shell d'application – et construisez un générateur pour cela. Simultanément, introduisez une règle d'application, comme le formatage de Prettier dans CI. Laissez l'équipe vivre l'avantage avant d'ajouter plus de complexité.

Documentez vos groupes électrogènes et vos conventions

Les générateurs sont inutiles si personne ne sait qu'ils existent. Ajoutez un répertoire à la racine de l'espace de travail avec une courte page énumérant tous les générateurs personnalisés, leurs options et leurs exemples. Inclure les conventions de nommage et les définitions de tags. Gardez ce document mis à jour au fur et à mesure que l'espace de travail évolue. Mieux encore, liez-le à partir de la sortie de la commande ou des messages d'erreur dans la règle de limite du module.

Utiliser la console Nx pour la découverte

Nx Console est un plugin VS Code et JetBrains qui fournit une interface graphique pour les générateurs en cours d'exécution. Il liste automatiquement tous les générateurs des plugins installés, y compris ceux que vous avez personnalisés. Encouragez votre équipe à l'utiliser – ils peuvent voir exactement ce qu'un générateur crée avant de l'exécuter, et les invites de schéma rendent les options claires.

Iterate basé sur les commentaires

Après quelques semaines, rassemblez les commentaires des développeurs : qu'est-ce que le générateur a manqué ? Quelle configuration ont-ils dû modifier manuellement après génération ? Répondez à ces points de douleur en mettant à jour le générateur. Traitez les générateurs comme un code vivant qui évolue aux côtés des pratiques de l'équipe. Nx facilite leur mise à jour car la logique du générateur est contrôlée et testée en version.

Mesure de l'impact de la cohérence

Comment savez-vous si vos modèles et normes personnalisés fonctionnent? Cherchez ces indicateurs principaux:

  • Réduction du temps de bootstrap:[ Combien de temps faut-il à un nouveau membre de l'équipe pour configurer un environnement de développement local et créer leur première fonctionnalité? Lorsque les générateurs gèrent la configuration, cela tombe d'heures à minutes.
  • Diminuer les modifications de configuration manuelles :[ Vérifiez l'historique git pour les commits qui ajustent les chemins de tsconfig, ajoutent des dépendances manquantes ou renomment les dossiers après la création initiale.
  • Avertissements de caractères dans la revue de code:[ Si vos portes CI fonctionnent, les développeurs voient des erreurs de caractères avant de pousser. Au fil du temps, le nombre de commentaires liés aux caractères dans les requêtes de tirage devrait diminuer.
  • Faster PR review cycles:[ Lorsque chaque projet ressemble, les évaluateurs peuvent se concentrer sur les décisions logiques et commerciales au lieu de discuter des arrangements de dossiers ou de la dénomination.

Suivez ces mesures de façon informelle avec votre équipe. Si vous utilisez un outil comme Code Climate ou un tableau de bord pour la latence CI, vous pouvez dériver des nombres objectifs. L'objectif n'est pas d'atteindre la perfection, mais de réduire continuellement les frictions causées par l'incohérence.

Conclusion

La cohérence dans un monorepo n'est pas un accident; elle est le résultat d'un outillage délibéré et de la discipline de l'équipe. Nx vous donne le pouvoir de coder les décisions architecturales de votre équipe en générateurs, de les faire appliquer avec des portes de lintage et de CI, et de les évoluer comme votre organisation l'apprend. Des modèles personnalisés éliminent l'étape manuelle, sujette aux erreurs, de copier et de coller les vieux projets. Les normes appliquées par et la configuration partagée empêchent la dérive au fil du temps. L'investissement dans la construction de ces générateurs se paie rapidement à mesure que votre espace de travail passe de dizaines de projets à des centaines. Commencez par un générateur, une règle et une étape de CI.