Paramétrage du projet (2023)

Les projets peuvent être configurés danspackage.json(si vous utilisez des scripts npm et non des exécuteurs Nx) etprojet.json(si tuutiliser des exécuteurs de tâches). Les deuxpackage.jsonetprojet.jsonles fichiers se trouvent dans le dossier de chaque projet. Nx fusionne les deux fichiers pour obtenir la configuration de chaque projet.

La configuration suivante créeconstruireettestcibles pour Nx.

Vous pouvez invoquernx construire malibounx test mylibsans aucune configuration supplémentaire.

Vous pouvez ajouter une configuration spécifique à Nx comme suit :

entrées et entrées nommées

Lecontributionsarray indique à Nx ce qu'il faut prendre en compte pour déterminer si une invocation particulière d'un script doit être un accès au cache ou non. Il existe trois types d'entrées :

Ensembles de fichiers

Exemples:

• {projectRoot}/**.*.ts
• pareil que{ensemble de fichiers : "{projectRoot}/**/*.ts"}
• {workspaceRoot}/jest.config.ts
• pareil que{ensemble de fichiers : "{workspaceRoot}/jest.config.ts}

Entrées d'exécution

Exemples:

• {exécution : "nœud -v"}

Notez que la valeur du résultat est hachée, elle n'est donc jamais affichée.

Variables d'environnement

Exemples:

• {env : "MY_ENV_VAR"}

Notez que la valeur du résultat est hachée, elle n'est donc jamais affichée.

Dépendances externes

Pour les plugins officiels, Nx trouve intelligemment un ensemble de dépendances externes qu'il hache pour la cible.nx: commandes d'exécutionest une exception à cela. Étant donné que vous pouvez spécifier n'importe quelle commande à exécuter, il n'est pas possible de déterminer quelles dépendances externes, le cas échéant, sont utilisées par la cible. Pour être sûr, Nx suppose que la mise à jour de toute dépendance externe invalide le cache de la cible.

Remarque : les plugins communautaires sont également traités commenx: commandes d'exécution

Ce type d'entrée vous permet de remplacer ce comportement prudent en spécifiant un ensemble de dépendances externes à hacher pour la cible.

Exemples:

Les cibles qui n'utilisent que des commandes nativement disponibles dans le terminal ne dépendront d'aucune dépendance externe. Spécifiez un tableau vide pour ne hacher aucune dépendance externe.

Si une cible utilise une commande d'un package npm, ce package doit être répertorié.

Sortie des tâches dépendantes

Cette entrée nous permet de dépendre de la sortie, plutôt que de l'entrée des tâches dépendantes. Nous pouvons spécifier le modèle glob pour qu'il corresponde uniquement au sous-ensemble des fichiers de sortie. LetransitifLe paramètre définit si la vérification et le modèle doivent être appliqués de manière récursive aux tâches dépendantes des tâches enfants.

Exemples:

Entrées nommées

Exemples:

• intrants : ["production"]
• pareil que"inputs": [{"input": "production", "projects": "self"}]dans les versions antérieures à Nx 16, ou"entrées": [{"entrée": "production"}]après version 16.

Souvent, le même glob apparaîtra à plusieurs endroits (par exemple, l'ensemble de fichiers prod exclura les fichiers de spécification pour tous les projets). Parce que les garder synchronisés est sujet aux erreurs, nous vous recommandons de définirentréesnommées, que vous pouvez ensuite référencer dans tous ces endroits.

Utilisation de ^

Exemples:

• entrées : ["^production"]
• pareil queentrées : [{"input": "production", "projects": "dépendances"}]avant Nx 16, ou"entrées": [{"entrée": "production", "dépendances": vrai }]après version 16.

Semblable àdépend de, les symboles "^" signifient "dépendances". C'est une idée très importante, alors illustrons-la par un exemple.

La configuration ci-dessus signifie que la cible de test dépend de tous les fichiers sources d'un projet donné et uniquement des sources prod (sources non test) de ses dépendances. En d'autres termes, il traite les sources de test comme privées.

Les sorties

Les cibles peuvent définir des sorties pour indiquer à Nx où la cible va créer des artefacts de fichier que Nx doit mettre en cache."outputs": ["{workspaceRoot}/dist/libs/mylib"]indique à Nx oùconstruirecible va créer des artefacts de fichier.

Cette configuration n'est généralement pas nécessaire. Nx est livré avec des valeurs par défaut raisonnables (importées dansnx.json) qui implémentent la configuration ci-dessus.

Plus précisément, par défaut, les emplacements suivants sont mis en cache pour les compilations :

• {workspaceRoot}/dist/{projectRoot},
• {projectRoot}/construction,
• {projectRoot}/dist,
• {projectRoot}/public

Exemple de base

Généralement, une cible écrit dans un répertoire ou un fichier spécifique. Ce qui suit indique à Nx de mettre en cachedist/libs/mylibetbuild/libs/mylib/main.js:

Spécification des globs

Parfois, plusieurs cibles peuvent écrire dans le même répertoire. Lorsque cela est possible, il est recommandé de diriger ces cibles dans des répertoires distincts.

Mais si ce qui précède n'est pas possible, globs (parsé par leGlobSetBibliothèque Rust) peuvent être spécifiés comme sorties pour ne mettre en cache qu'un ensemble de fichiers plutôt que l'ensemble du répertoire.

Des modèles plus avancés peuvent être utilisés pour exclure des fichiers et des dossiers sur une seule ligne

dépend de

Les cibles peuvent dépendre d'autres cibles. Voici la partie pertinente du fichier de configuration :

Un scénario courant consiste à créer les dépendances d'un projet avant de générer le projet. C'est ce que le"dépend de": ["^build"]propriété de laconstruirecible configure. Il dit à Nx qu'avant de pouvoir construiremalibil faut s'assurer quemalibLes dépendances de sont également construites. Cela ne signifie pas que Nx va réexécuter ces versions. Si les bons artefacts sont déjà au bon endroit, Nx ne fera rien. S'ils ne sont pas au bon endroit, mais qu'ils sont disponibles dans le cache, Nx les récupérera dans le cache.

Un autre scénario courant est qu'une cible dépende d'une autre cible du même projet. Par exemple,"dépend de": ["construire"]de latestla cible indique à Nx qu'avant de pouvoir testermalibil faut s'assurer quemalibest construit, ce qui entraîneramalibLes dépendances sont également en cours de construction.

Vous pouvez également exprimer des dépendances de tâches avec une syntaxe d'objet :

Exemples

Vous pouvez écrire la configuration abrégée ci-dessus dans la syntaxe de l'objet comme ceci :

Avec la syntaxe étendue, vous disposez également d'une troisième option disponible pour configurer la manière de gérer les paramètres transmis à la cible. Vous pouvez soit les transférer, soit les ignorer (par défaut).

Cela fonctionne également lors de la définition d'une relation pour la cible du projet lui-même en utilisant"projets": "moi":

De plus, lorsque vous utilisez la syntaxe d'objet étendue, vous pouvez spécifier des projets individuels dans la version 16 ou supérieure.

Cette configuration n'est généralement pas nécessaire. Nx est livré avec des valeurs par défaut raisonnables (importées dansnx.json) qui implémentent la configuration ci-dessus.

Mots clés

Vous pouvez annoter vos projets avecMots cléscomme suit:

Tu peuxconfigurer les règles de charpie à l'aide de ces balisespour, par exemple, s'assurer que les bibliothèques appartenant àmon équipene dépendent pas des bibliothèques appartiennent àl'équipe.

Dépendancesimplicites

Nx utilise une puissante analyse du code source pour déterminer le graphique de projet de votre espace de travail. Certaines dépendances ne peuvent pas être déduites statiquement, vous pouvez donc les définir manuellement comme ceci. LeDépendancesimplicitesla propriété est analysée avec lemini-matchbibliothèque, afin que vous puissiez revoir cette syntaxe pour des cas d'utilisation plus avancés.

Vous pouvez également supprimer une dépendance comme suit :

Une dépendance implicite pourrait également être un modèle glob :

Inclure les fichiers package.json en tant que projets dans le graphique

N'importe quelpackage.jsonfichier référencé par leespaces de travailpropriété à la racinepackage.jsonfichier sera inclus en tant que projet dans le graphique. Si vous utilisez Lerna, les projets définis dansclay.jsonsera inclus. Si vous utilisez pnpm, les projets définis danspnpm-workspace.ymlsera inclus.

Si vous souhaitez ignorer unpackage.jsonfichier, excluez-le de ces outils. Par exemple, vous pouvez ajouter!packages/monprojetauespaces de travailpropriété.

Ignorer les scripts package.json

Nx fusionne les scripts package.json avec vos cibles définies dans project.json. Si vous souhaitez que certains scripts ne soient utilisés que comme cibles Nx, vous pouvez les spécifier dans le champscripts incluspropriété du package.json du projet.