Aller au contenu principal
Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Configuration

La configuration de Lerna est répartie entre deux fichiers : lerna.json et nx.json.

Lerna.json

npmClient​

Il est important de définir cette valeur si vous n'utilisez pas npm comme gestionnaire de paquets (par exemple avec yarn ou pnpm) afin que Lerna puisse adapter sa logique interne lors de la résolution de la configuration et des paquets. Ceci est particulièrement vrai pour pnpm car il utilise un fichier séparé pnpm-workspaces.yaml pour définir sa configuration des espaces de travail.

packages​

Par défaut, Lerna tente de réutiliser toute configuration workspaces provenant de votre gestionnaire de paquets. Si vous préférez spécifier un sous-ensemble des paquets disponibles pour les opérations de Lerna, utilisez la propriété packages qui indiquera à Lerna où chercher les fichiers package.json.

lerna.json
{
  "packages": ["packages/*"]
}

version​

Lerna propose deux modes de publication des paquets : fixed et independent. En mode fixed, tous les paquets affectés sont publiés avec la même version. La dernière version publiée est enregistrée dans lerna.json comme suit :

lerna.json
{
  "version": "1.2.0"
}

En mode independent, chaque paquet est versionné séparément, et lerna.json ressemblera à ceci :

lerna.json
{
  "version": "independent"
}

Voir la documentation sur le versionnage et la publication pour plus de détails.

commands​

Le fichier lerna.json peut également encoder des options pour chaque commande de cette manière :

{
  "command": {
    "version": {
      "allowBranch": "main",
      "conventionalCommits": true
    }
  }
}

Retrouvez les options disponibles dans la documentation de l'API.

Nx.json

NOTE: "{projectRoot}" et "{workspaceRoot}" sont des syntaxes spéciales prises en charge par l'exécuteur de tâches, qui seront interpolées de manière appropriée en interne lors de l'exécution de la commande. Vous ne devez donc pas remplacer "{projectRoot}" ou "{workspaceRoot}" par des chemins fixes car cela rend votre configuration moins flexible.

nx.json
{
  "namedInputs": {
    "default": ["{projectRoot}/**/*"],
    "prod": ["!{projectRoot}/**/*.spec.tsx"]
  },
  "targetDefaults": {
    "build": {
      "dependsOn": ["prebuild", "^build"],
      "inputs": ["prod", "^prod"],
      "outputs": ["{projectRoot}/dist"],
      "cache": true
    },
    "test": {
      "inputs": ["default", "^prod", "{workspaceRoot}/jest.config.ts"],
      "cache": true
    }
  }
}

Valeurs par défaut des cibles​

Les cibles correspondent aux noms des scripts npm. Vous pouvez ajouter des métadonnées associées, par exemple au script de build de chaque projet du dépôt, dans la section targetDefaults.

cache​

Lorsque défini sur true, indique à Nx de mettre en cache les résultats d'exécution du script. Dans la plupart des dépôts, toutes les tâches non longues (c'est-à-dire hors serve) devraient être cachable.

Dépendances (DependsOn)​

Les cibles peuvent dépendre d'autres cibles. Un scénario courant consiste à devoir d'abord construire les dépendances d'un projet avant de construire le projet lui-même. La propriété dependsOn permet de définir les dépendances d'une cible individuelle.

"dependsOn": [ "prebuild", "^build"] indique à Nx que chaque script build nécessite d'exécuter au préalable le script prebuild du même projet et le script build de toutes ses dépendances.

Entrées et entrées nommées (Inputs & Named Inputs)​

Le tableau inputs indique à Nx quels éléments considérer pour déterminer si une exécution spécifique d'un script doit être un succès de cache. Il existe trois types d'entrées :

Ensembles de fichiers

Exemples :

  • {projectRoot}/**.*.ts

  • équivalent à {fileset: "{projectRoot}/**/*.ts"}

  • {workspaceRoot}/jest.config.ts

  • équivalent à {fileset: "{workspaceRoot}/jest.config.ts}

Entrées d'exécution

Exemples :

  • {runtime: "node -v"}

Notez que la valeur résultante est hachée, donc jamais affichée.

Variables d'environnement

Exemples :

  • {env: "MY_ENV_VAR"}

Notez que la valeur résultante est hachée, donc jamais affichée.

Entrées nommées (Named Inputs)

Exemples :

  • inputs: ["prod"]

  • équivalent à inputs: [{input: "prod", projects: "self"}]

Souvent, le même glob apparaît à plusieurs endroits (ex: le fileset "prod" exclut les fichiers de test pour tous les projets). Comme maintenir leur synchronisation est source d'erreurs, nous recommandons de définir des entrées nommées que vous pourrez référencer partout.

Utilisation du symbole ^​

Exemples :

  • inputs: ["^prod"]

  • équivalent à inputs: [{input: "prod", projects: "dependencies"}]

Comme pour dependsOn, le symbole "^" signifie "dépendances". Voici un exemple pour illustrer ce concept important :

"test": {
  "inputs": [ "default", "^prod" ]
}

La configuration ci-dessus signifie que la cible "test" dépend de tous les fichiers sources d'un projet donné, mais uniquement des sources "prod" (non-test) de ses dépendances. En d'autres termes, elle traite les sources de test comme privées. Si votre projet remixapp dépend de la bibliothèque header, modifier les tests de header n'affectera pas la cible "test" de remixapp.

Sorties (Outputs)​

"outputs": ["{projectRoot}/dist"] indique à Nx où le script de build va créer les artefacts. Cette valeur correspond d'ailleurs au comportement par défaut, on peut donc l'omettre ici. "outputs": [] signifie que la cible "test" ne crée aucun artefact sur le disque. Vous pouvez lister autant de sorties que nécessaire, y compris des globs ou fichiers individuels.

Cette configuration est généralement facultative. Nx fournit des valeurs par défaut raisonnables implémentant le comportement décrit.

Configuration spécifique aux projets​

Dans de nombreux espaces de travail où les projets sont similaires, nx.json contient toute la configuration Nx. Parfois, il est utile d'avoir une configuration spécifique à un projet, placée dans son fichier package.json.

package.json
{
  "name": "parent",
  "scripts": {
    "build": "...",
    "test": "..."
  },
  "dependencies": {...},
  "nx": {
    "namedInputs": {
      "prod": [
        "!{projectRoot}/**/*.test.tsx",
        "{workspaceRoot}/configs/webpack.conf.js"
      ]
    },
    "targets": {
      "build": {
        "dependsOn": [
          "^build"
        ],
        "inputs": [
          "prod",
          "^prod"
        ],
        "outputs": [
          "{workspaceRoot}/dist/parent"
        ]
      }
    }
    "implicitDependencies": ["projecta", "!projectb"]
  }
}

Notez que les namedInputs et targetDefaults définis dans nx.json sont simplement des valeurs par défaut. Si vous copiez cette configuration dans chaque fichier package.json, le résultat sera identique.

Autrement dit, chaque projet possède un ensemble d'entrées nommées défini comme suit : {...namedInputsFromNxJson, ...namedInputsFromProjectsPackageJson}. Le dependsOn de chaque cible/script est défini comme dependsOnFromProjectsPackageJson || dependsOnFromNxJson. La même logique s'applique aux inputs et outputs.

Entrées et entrées nommées (Inputs & Named Inputs)​

Définir des inputs pour une cible remplace l'ensemble d'entrées défini pour ce nom de cible dans nx.json. En pseudocode : inputs = packageJson.targets.build.inputs || nxJson.targetDefaults.build.inputs.

Vous pouvez aussi définir et redéfinir des entrées nommées. Cela permet un cas d'usage clé où votre nx.json définit des éléments comme ceci (appliqué à tous les projets) :

"test": {
  "inputs": [
    "default",
    "^prod"
  ]
}

Et où les projets peuvent définir leur propre fileset "prod" sans avoir à redéfinir les entrées pour la cible test.

package.json
{
  "name": "parent",
  "scripts": {
    "build": "...",
    "test": "..."
  },
  "dependencies": {...},
  "nx": {
    "namedInputs": {
      "prod": [
        "!{projectRoot}/**/*.test.js",
        "{workspacRoot}/jest.config.js"
      ]
    }
  }
}

Dans ce cas, Nx utilisera la bonne entrée prod pour chaque projet.

Dépendances (DependsOn)​

Définir dependsOn pour une cible remplace le dependsOn défini pour ce nom de cible dans nx.json. En pseudocode : dependsOn = packageJson.targets.build.dependsOn || nxJson.targetDefaults.build.dependsOn.

Sorties (Outputs)​

Définir des outputs pour une cible donnée remplacera les outputs pour ce nom de cible définis dans nx.json. En utilisant du pseudocode : outputs = packageJson.targets.build.outputs || nxJson.targetDefaults.build.outputs.

implicitDependencies​

La ligne "implicitDependencies": ["projecta", "!projectb"] indique à Nx que le projet parent dépend de projecta même s'il n'existe pas de dépendance dans son package.json. Nx traitera cette dépendance de la même manière que les dépendances explicites. Elle indique également à Nx que même s'il existe une dépendance explicite sur projectb, celle-ci doit être ignorée.

Configuration supplémentaire​

Pour des moyens supplémentaires de configurer les tâches et la mise en cache, consultez la documentation Nx correspondante.