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 →

Fonctionnement du cache

Avant d'exécuter une tâche, Lerna calcule son hash de calcul. Tant que ce hash reste identique, le résultat de l'exécution de la tâche sera le même.

Par défaut, le hash de calcul pour une commande comme lerna run test --scope=remixapp inclut :

• Tous les fichiers sources de remixapp et de ses dépendances

• La configuration globale pertinente

• Les versions des dépendances externes

• Les valeurs d'exécution fournies par l'utilisateur comme la version de Node

• Les flags de commande CLI

Ce comportement est personnalisable. Par exemple, les vérifications de lint peuvent dépendre uniquement du code source du projet et des configurations globales. Les builds peuvent dépendre des fichiers dts des librairies compilées plutôt que de leur code source.

Après avoir calculé le hash d'une tâche, Lerna vérifie si ce calcul exact a déjà été effectué. Il commence par vérifier localement, puis si absent et si un cache distant est configuré, il vérifie à distance.

Si Lerna trouve le calcul, il le récupère et le rejoue. Lerna place les fichiers aux bons emplacements et reproduit la sortie terminal. Pour l'utilisateur, la commande s'est exécutée identiquement, mais beaucoup plus rapidement.

Si Lerna ne trouve pas de hash correspondant, il exécute la tâche. Après son achèvement, il stocke les sorties et les logs localement (et à distance si configuré). Ce processus est transparent et ne nécessite aucune intervention.

Bien que le concept soit simple, Lerna l'optimise pour une expérience optimale. Par exemple, il :

• Capture stdout et stderr pour garantir une sortie identique, y compris sous Windows

• Minimise les E/S en mémorisant l'emplacement des fichiers rejoués

• Affiche uniquement les sorties pertinentes lors du traitement d'un grand graphe de tâches

• Fournit des outils pour diagnostiquer les absences du cache, parmi d'autres optimisations

Dans un espace de travail évolutif, le graphe de tâches ressemble plutôt à ceci :

Ces optimisations sont cruciales pour utiliser Lerna dans des espaces de travail complexes. Seul le travail minimal est effectué, le reste est soit conservé tel quel, soit restauré depuis le cache.

Entrées pour le hachage du code source

Le résultat du build ou des tests d'une application/librairie dépend de son code source et des codes sources de toutes ses dépendances (directes ou indirectes).

Par défaut, Lerna adopte une approche conservative. Lors de l'exécution de lerna run test --scope=remixapp, il considère tous les fichiers des répertoires remixapp, header et footer (dépendances). Cela peut causer des absences de cache inutiles. Par exemple, modifier un fichier spec de footer n'affecte pas le résultat des tests de remixapp.

Nous pouvons définir une configuration plus précise comme suit :

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": {
      "inputs": ["prod", "^prod"]
    },
    "test": {
      "inputs": ["default", "^prod", "{workspaceRoot}/jest.config.ts"]
    }
  }
}

Avec cette configuration, le script de build ne prendra en compte que les fichiers non-tests de remixapp, header et footer. Le script de test considérera tous les fichiers sources du projet testé et uniquement les fichiers non-tests de ses dépendances. Le script de test prendra également en compte le fichier de configuration jest à la racine de l'espace de travail.

Entrées de hachage d'exécution

Vos cibles peuvent également dépendre de valeurs d'exécution.

nx.json

{
  "targetDefaults": {
    "build": {
      "inputs": [{ "env": "MY_ENV_NAME" }, { "runtime": "node -v" }]
    }
  }
}

Entrées de hachage d'arguments

Enfin, en plus des entrées de hachage de code source et d'exécution, Lerna doit considérer les arguments : Par exemple, lerna run build --scope=remixapp et lerna run build --scope=remixapp -- --flag=true produisent des résultats différents.

Notez que seuls les flags passés aux scripts npm eux-mêmes affectent les résultats du calcul. Par exemple, les commandes suivantes sont identiques du point de vue du cache.

npx lerna run build --scope=remixapp
npx lerna run build --ignore=header,footer

Autrement dit, Lerna ne met pas en cache ce que le développeur saisit dans le terminal.

Si vous build/test/lint… plusieurs projets, chaque build individuel a sa propre valeur de hachage et sera soit récupéré du cache, soit exécuté. Cela signifie que du point de vue du cache, la commande suivante :

npx lerna run build --scope=header,footer

est identique aux deux commandes suivantes :

npx lerna run build --scope=header
npx lerna run build --scope=footer

Qu'est-ce qui est mis en cache

Lerna opère au niveau du processus. Quel que soit l'outil utilisé pour build/test/linter/etc. votre projet, les résultats sont mis en cache.

Lerna configure des hooks pour collecter stdout/stderr avant d'exécuter la commande. Toute la sortie est mise en cache puis relue lors d'un succès de cache.

Lerna met également en cache les fichiers générés par une commande. La liste des fichiers/dossiers est spécifiée dans la propriété outputs du package.json du projet :

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.

E.g. packages/my-project/package.json

{
  "nx": {
    "targets": {
      "build": {
        "outputs": ["{projectRoot}/build", "{projectRoot}/public/build"]
      }
    }
  }
}

Si la propriété outputs pour une cible donnée n'est pas définie dans le fichier package.json du projet, Lerna consultera la section targetDefaults du nx.json :

nx.json

{
  ...
  "targetDefaults": {
    "build": {
      "dependsOn": [
        "^build"
      ],
      "outputs": [
        "{projectRoot}/dist",
        "{projectRoot}/build",
        "{projectRoot}/public/build"
      ]
    }
  }
}

Si aucune des deux n'est définie, Lerna mettra par défaut en cache les dossiers dist et build à la racine du dépôt.

Contourner le cache

Parfois vous souhaitez ignorer le cache. Si par exemple vous mesurez les performances d'une commande, vous pouvez utiliser le flag --skip-nx-cache pour ignorer la vérification du cache de calcul.

npx lerna run build --skip-nx-cache
npx lerna run test --skip-nx-cache

Configuration supplémentaire

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