Un outil de gestion de projets JavaScript avec plusieurs packages.

• À propos de
• Mise en route
• Comment Cela fonctionne
• Dépannage
• Commandes
• Divers
• Lerna.json
• Flags

À propos de

Le fractionnement de grandes bases de code en paquets séparés indépendamment versionnés est extrêmement utile pour le partage de code. Cependant, apporter des modifications à de nombreux dépôts est compliqué et difficile à suivre, et les tests entre dépôts se compliquent très rapidement.

Pour résoudre ces problèmes (et bien d’autres), certains projets organiseront leurs bases de code en dépôts multi-paquets (parfois appelés monorepos). Des projets comme Babel, React, Angular, Ember, Meteor, Jest et bien d’autres développent tous leurs paquets dans un seul référentiel.

Lerna est un outil qui optimise le flux de travail autour de la gestion des dépôts multi-paquets avec git et npm.

Lerna peut également réduire les besoins en temps et en espace pour de nombreuses copies de paquets dans les environnements de développement et de construction – normalement un inconvénient de diviser un projet en plusieurs paquets NPM distincts. Voir la documentation du palan pour plus de détails.

À quoi ressemble un dépôt Lerna ?

Il y en a en fait très peu. Vous avez un système de fichiers qui ressemble à ceci:

my-lerna-repo/ package.json packages/ package-1/ package.json package-2/ package.json

Que peut faire Lerna?

Les deux commandes principales de Lerna sont lerna bootstrap et lerna publish.

bootstrap liera les dépendances du dépôt ensemble. publish aidera à publier les paquets mis à jour.

Mise en route

Les instructions ci-dessous concernent Lerna 2.x. Nous vous recommandons de l’utiliser au lieu de 1.x pour un nouveau projet Lerna. Vérifiez le wiki si vous avez besoin de voir le 1.x LISEZ-MOI.

Commençons par installer Lerna globalement avec npm.

$ npm install --global lerna

Ensuite, nous créerons un nouveau dépôt git:

$ git init lerna-repo$ cd lerna-repo

Et maintenant, transformons-le en un repo Lerna:

$ lerna init

Votre référentiel devrait maintenant ressembler à ceci:

lerna-repo/ packages/ package.json lerna.json

Cela créera un fichier de configuration lerna.json ainsi qu’un dossier packages.

Comment Ça marche

Lerna vous permet de gérer votre projet en utilisant l’un des deux modes : Fixe ou Indépendant.

Mode fixe/verrouillé (par défaut)

Mode fixe Les projets Lerna fonctionnent sur une seule ligne de version. La version est conservée dans le fichier lerna.json à la racine de votre projet sous la clé version. Lorsque vous exécutez lerna publish, si un module a été mis à jour depuis la dernière version, il sera mis à jour vers la nouvelle version que vous publiez. Cela signifie que vous ne publiez une nouvelle version d’un package que lorsque vous en avez besoin.

C’est le mode que Babel utilise actuellement. Utilisez-le si vous souhaitez lier automatiquement toutes les versions de paquets. Un problème avec cette approche est qu’un changement majeur dans n’importe quel paquet aura pour conséquence que tous les paquets auront une nouvelle version majeure.

Mode indépendant (independentindependent)

Mode indépendant Les projets Lerna permettent aux responsables d’incrémenter les versions de paquets indépendamment les unes des autres. Chaque fois que vous publiez, vous recevrez une invite pour chaque paquet qui a changé afin de spécifier s’il s’agit d’un correctif, d’une modification mineure, majeure ou personnalisée.

Le mode indépendant vous permet de mettre à jour plus spécifiquement les versions de chaque paquet et est logique pour un groupe de composants. Combiner ce mode avec quelque chose comme la libération sémantique le rendrait moins douloureux. (Il y a déjà du travail à ce sujet chez atlassian/lerna-semantic-release).

La touche version de lerna.json est ignorée en mode indépendant.

Dépannage

Si vous rencontrez des problèmes lors de l’utilisation de Lerna, veuillez consulter notre document de dépannage où vous trouverez peut-être la réponse à votre problème.

Foire aux questions

Voir FAQ.md .

Commandes

initialisation

$ lerna init

Créez un nouveau dépôt Lerna ou mettez à niveau un dépôt existant vers la version actuelle de Lerna.

Lerna suppose que le dépôt a déjà été initialisé avec git init.

Lors de l’exécution, cette commande va:

1. Ajoutez lerna en tant que devDependency en package.json s’il n’existe pas déjà.
2. Créez un fichier de configuration lerna.json pour stocker le numéro version.

Exemple de sortie sur un nouveau dépôt git:

$ lerna initlerna info version v2.0.0lerna info Updating package.jsonlerna info Creating lerna.jsonlerna success Initialized Lerna files

— indépendant, -i

$ lerna init --independent

Cet indicateur indique à Lerna d’utiliser le mode de gestion de versions indépendant.

exact exact

$ lerna init --exact

Par défaut, lerna init utilisera une plage de carets lors de l’ajout ou de la mise à jour de la version locale de lerna, tout comme npm install --save-dev lerna.

Pour conserver le lerna 1.x comportement de la comparaison « exacte », passez cet indicateur. Il configurera lerna.json pour appliquer une correspondance exacte pour toutes les exécutions ultérieures.

{ "lerna": "2.0.0", "command": { "init": { "exact": true } }, "version": "0.0.0"}

bootstrap

$ lerna bootstrap

Bootstrap les paquets dans le dépôt Lerna actuel. Installe toutes leurs dépendances et relie toutes les dépendances croisées.

Lors de l’exécution, cette commande va:

1. npm install toutes les dépendances externes de chaque paquet.
2. Lient ensemble tous les Lerna packages qui sont des dépendances les uns des autres.
3. npm prepublish tous les paquets amorçés.

lerna bootstrap respecte les drapeaux --ignore, --scope et --include-filtered-dependencies (voir Drapeaux).

Transmettez des arguments supplémentaires au client npm en les plaçant après --:

$ lerna bootstrap -- --production --no-optional

Peut également être configuré dans lerna.json:

{ ... "npmClient": "yarn", "npmClientArgs": }

Comment bootstrap fonctionne

Utilisons babel comme exemple.

• babel-generator et source-map (entre autres) sont des dépendances de babel-core.
• babel-core‘ s package.json répertorie ces deux paquets en tant que clés dans dependencies, comme indiqué ci-dessous.

// babel-core package.json{ "name": "babel-core", ... "dependencies": { ... "babel-generator": "^6.9.0", ... "source-map": "^0.5.0" }}

• Lerna vérifie si chaque dépendance fait également partie du dépôt Lerna.
  • Dans cet exemple, babel-generator peut être une dépendance interne, tandis que source-map est toujours une dépendance externe.
  • La version de babel-generator dans la package.json de babel-core est satisfaite par packages/babel-generator, passant pour une dépendance interne.
  • source-map est npm install ed (ou yarn ed) comme la normale.
• packages/babel-core/node_modules/babel-generator liens symboliques vers packages/babel-generator
• Cela permet d’importer des répertoires imbriqués

Notes:

• Lorsqu’une version de dépendance dans un paquet n’est pas satisfaite par un paquet du même nom dans le dépôt, elle sera npm installed (ou yarn ed) comme d’habitude.
• Les balises Dist, comme latest, ne satisfont pas les plages semver.
• Les dépendances circulaires entraînent des liens symboliques circulaires qui peuvent avoir un impact sur votre éditeur /E.

Webstorm se verrouille lorsque des liens symboliques circulaires sont présents. Pour éviter cela, ajoutez node_modules à la liste des fichiers et dossiers ignorés dans Preferences | Editor | File Types | Ignored files and folders.

publier

$ lerna publish

Publier des packages dans le projet Lerna actuel. Lors de son exécution, cette commande effectue les opérations suivantes :

Crée une nouvelle version des paquets qui ont été mis à jour. Demande une nouvelle version. Crée un nouveau commit/tag git en cours de publication sur npm.

Plus précisément, cette commande va:

1. Exécutez l’équivalent de lerna updated pour déterminer quels paquets doivent être publiés.
2. Si nécessaire, incrémentez la touche version en lerna.json.
3. Mettez à jour les package.json de tous les paquets mis à jour vers leurs nouvelles versions.
4. Met à jour toutes les dépendances des paquets mis à jour avec les nouvelles versions, spécifiées avec un caret (^).
5. Créez un nouveau commit git et une balise pour la nouvelle version.
6. Publiez les paquets mis à jour dans npm.

Lerna ne publiera pas les paquets marqués comme privés ("private": true dans le package.json).

— exact

$ lerna publish --exact

Lorsqu’il est exécuté avec cet indicateur, publish spécifiera exactement les dépendances mises à jour dans les paquets mis à jour (sans ponctuation), au lieu d’être compatibles avec semver (avec un ^).

Pour plus d’informations, voir le paquet.documentation sur les dépendances json.

–npm-tag

$ lerna publish --npm-tag=next

Lorsqu’il est exécuté avec cet indicateur, publish publiera dans npm avec le dist-tag npm donné (par défaut latest).

Cette option peut être utilisée pour publier une version prerelease ou beta.

Note: la balise latest est celle utilisée lorsqu’un utilisateur exécute npm install my-package. Pour installer une balise différente, un utilisateur peut exécuter npm install [email protected].

— canary, -c

$ lerna publish --canary$ lerna publish --canary=beta

Lorsqu’il est exécuté avec cet indicateur, publish publie les paquets de manière plus granulaire (par commit). Avant de publier sur npm, il crée la nouvelle balise version en prenant la version actuelle, en la cognant à la version mineure suivante, en ajoutant le suffixe méta fourni (par défaut alpha) et en ajoutant le sha git actuel (ex: 1.0.0 devient 1.1.0-alpha.81e3b443).

Le cas d’utilisation prévu pour cet indicateur est une version par niveau de validation ou une version nocturne.

— conventional-commits

$ lerna publish --conventional-commits

Lorsqu’il est exécuté avec cet indicateur, publish utilisera la spécification Conventional Commits pour déterminer la bosse de version et générer le JOURNAL des modifications

–git-remote

$ lerna publish --git-remote upstream

Lorsqu’il est exécuté avec cet indicateur, publish poussera les modifications git vers la télécommande spécifiée au lieu de origin.

skipskip-git

$ lerna publish --skip-git

Lorsqu’il est exécuté avec cet indicateur, publish publiera dans npm sans exécuter aucune des commandes git.

Publier uniquement dans npm ; ignorer la validation, le marquage et la poussée des modifications git (cela n’affecte que la publication).

— skip-npm

$ lerna publish --skip-npm

Lorsqu’il est exécuté avec cet indicateur, publish mettra à jour toutes les versions de paquets et les versions de dépendances package.json, mais il ne publiera pas réellement les paquets dans npm.

Ceci était utile comme solution de contournement pour un problème npm qui a depuis été corrigé. Lors de la publication avec des modifications README, utilisez --skip-npm et effectuez la dernière npm publish à la main pour chaque paquet.

Cet indicateur peut être combiné avec --skip-git pour simplement mettre à jour les versions et les dépendances, sans valider, étiqueter, pousser ou publier.

Ne met à jour que les versions et les dépendances ; ne publiez pas réellement (cela affecte uniquement la publication).

— force-publish

$ lerna publish --force-publish=package-2,package-4# force publish all packages$ lerna publish --force-publish=*

Lorsqu’il est exécuté avec cet indicateur, publish forcera la publication des paquets spécifiés (séparés par des virgules) ou de tous les paquets en utilisant *.

Cela ignorera la vérification lerna updated des paquets modifiés et forcera la mise à jour d’un paquet qui n’avait pas de modification git diff.

— oui

$ lerna publish --canary --yes# skips `Are you sure you want to publish the above changes?`

Lorsqu’il est exécuté avec cet indicateur, publish ignore toutes les invites de confirmation. Utile en intégration continue (CI) pour répondre automatiquement à l’invite de confirmation de publication.

–cd-version

Lorsqu’il est exécuté avec cet indicateur, publish ignore l’invite de sélection de version (en mode indépendant) et utilise la prochaine version sémantique spécifiée. Vous devez toujours utiliser l’indicateur --yes pour éviter toutes les invites. Ceci est utile lorsque les systèmes de génération doivent publier sans invite de commande. Fonctionne en modes normal et indépendant.

prepre-id

–repo-version

$ lerna publish --repo-version 1.0.1# applies version and skips `Select a new version for...` prompt

Lorsqu’il est exécuté avec cet indicateur, publish ignore l’invite de sélection de version et utilise la version spécifiée. Utile pour contourner l’invite de saisie utilisateur si vous savez déjà quelle version publier.

messagemessage, -m

Lorsqu’il est exécuté avec cet indicateur, publish utilisera le message fourni lors de la validation des mises à jour de version pour publication. Utile pour intégrer lerna dans des projets qui s’attendent à ce que les messages de commit respectent certaines directives, telles que les projets qui utilisent commitizen et / ou semantic-release.

Si le message contient %s, il sera remplacé par le nouveau numéro de version de la version globale préfixé par un « v ». Notez que cela ne s’applique que lorsque vous utilisez le mode de gestion des versions « fixe » par défaut, car il n’y a pas de version « globale » lorsque vous utilisez --independent.

mise à jour

$ lerna updated

Vérifiez quels packages ont changé depuis la dernière version (la dernière balise git).

Lerna détermine la dernière balise git créée et exécute git diff --name-only v6.8.1 pour obtenir tous les fichiers modifiés depuis cette balise. Il renvoie ensuite un tableau de paquets contenant un fichier mis à jour.

Notez que la configuration de la commande publish affecte également la commande updated. Par exemple config.publish.ignore

— json

$ lerna updated --json

Lorsqu’il est exécuté avec cet indicateur, updated renvoie un tableau d’objets au format suivant:

nettoyez

$ lerna clean

Supprimez le répertoire node_modules de tous les paquets.

lerna clean respecte les drapeaux --ignore, --scope et --yes (voir Drapeaux).

diff

$ lerna diff $ lerna diff# diff a specific package$ lerna diff package-name

Diff tous les paquets ou un seul paquet depuis la dernière version.

Similaire à lerna updated. Cette commande s’exécute git diff.

ls

$ lerna ls

Liste tous les paquets publics dans le dépôt Lerna actuel.

lerna ls respecte les drapeaux --ignore et --scope (voir Drapeaux).

–json

$ lerna ls --json

Lorsqu’il est exécuté avec cet indicateur, ls renverra un tableau d’objets au format suivant:

exécutez

Exécutez un script npm dans chaque paquet qui contient ce script. Un double tiret (--) est nécessaire pour transmettre des arguments pointillés à l’exécution du script.

lerna run respecte le --concurrency, --scope, --ignore, --stream, et --parallel drapeaux (voir Drapeaux).

$ lerna run --scope my-component test

Remarque : Il est conseillé de limiter la portée de cette commande (et lerna exec, ci-dessous) lors de l’utilisation de l’indicateur --parallel, car générer des dizaines de sous-processus peut nuire à l’équanimité de votre shell (ou à la limite maximale du descripteur de fichier, par exemple). YMMV

exec

$ lerna exec -- <command> # runs the command in all packages$ lerna exec -- rm -rf ./node_modules$ lerna exec -- protractor conf.js

Exécute une commande arbitraire dans chaque paquet. Un double tiret (--) est nécessaire pour passer des indicateurs pointillés à la commande générée, mais n’est pas nécessaire lorsque tous les arguments sont positionnels.

lerna exec respecte la --concurrency, --scope, --ignore, et --parallel drapeaux (voir Drapeaux).

$ lerna exec --scope my-component -- ls -la

Pour générer des processus de longue durée, passez l’indicateur --parallel:

# transpile all modules as they change in every package$ lerna exec --parallel -- babel src -d lib -w

Vous pouvez également obtenir le nom du paquet actuel via la variable d’environnement LERNA_PACKAGE_NAME:

$ lerna exec -- npm view $LERNA_PACKAGE_NAME

Vous pouvez également exécuter un script situé dans le répertoire racine, dans une structure de répertoire compliquée via la variable d’environnement LERNA_ROOT_PATH:

$ lerna exec -- node $LERNA_ROOT_PATH/scripts/some-script.js

Astuce : Les commandes sont générées en parallèle, en utilisant la simultanéité donnée (sauf avec --parallel). La sortie est acheminée, donc non déterministe. Si vous souhaitez exécuter la commande dans un paquet après l’autre, utilisez-la comme ceci:

$ lerna exec --concurrency 1 -- ls -la

— bail

$ lerna exec --bail=<boolean> <command>

Cet indicateur indique si la commande exec doit ou non arrêter l’exécution en cas d’erreur générée par l’un des sous-processus générés. Sa valeur par défaut est true.

import

$ lerna import <path-to-external-repository>

Import le paquet à <path-to-external-repository>, avec l’historique des validations, dans packages/<directory-name>. Les auteurs de validation originaux, les dates et les messages sont conservés. Les validations sont appliquées à la branche en cours.

Ceci est utile pour rassembler des paquets autonomes préexistants dans un dépôt Lerna. Chaque commit est modifié pour apporter des modifications par rapport au répertoire des paquets. Ainsi, par exemple, le commit qui a ajouté package.json ajoutera à la place packages/<directory-name>/package.json.

Divers

Lerna se connecte à un fichier lerna-debug.log (identique à npm-debug.log) lorsqu’il rencontre une erreur lors de l’exécution d’une commande.

Lerna prend également en charge les paquets de portée.

L’exécution de lerna sans arguments affichera toutes les commandes/options.

lerna.json

{ "lerna": "2.0.0", "version": "1.1.3", "commands": { "publish": { "ignore": }, "bootstrap": { "ignore": "component-*" } }, "packages": }

• lerna: la version actuelle de Lerna est utilisée.
• version: la version actuelle du référentiel.
• commands.publish.ignore: un tableau de globes qui ne seront pas inclus dans lerna updated/publish. Utilisez-le pour éviter de publier une nouvelle version inutilement pour des modifications, telles que la correction d’une faute de frappe README.md.
• commands.bootstrap.ignore: un tableau de globs qui ne seront pas amorçés lors de l’exécution de la commande lerna bootstrap.
• commands.bootstrap.scope: un tableau de globs qui limite les paquets qui seront amorçés lors de l’exécution de la commande lerna bootstrap.
• packages: Tableau de globes à utiliser comme emplacements de paquets.

Dépendances communes

La plupart des devDependencies peuvent être extraites jusqu’à la racine d’un dépôt Lerna.

Cela présente quelques avantages:

• Tous les paquets utilisent la même version d’une dépendance donnée
• Peut maintenir les dépendances à la racine à jour avec un outil automatisé tel que GreenKeeper
• Le temps d’installation des dépendances est réduit
• Moins de stockage est nécessaire

Notez que devDependencies Fournir des exécutables « binaires  » qui permettent de sont utilisés par les scripts npm doivent encore être installés directement dans chaque package où ils sont utilisés.

Par exemple, la dépendance nsp est nécessaire dans ce cas pour que lerna run nsp (et npm run nsp dans le répertoire du paquet) fonctionne correctement:

{ "scripts": { "nsp": "nsp" }, "devDependencies": { "nsp": "^2.3.3" }}

Flags

Les options de Lerna peuvent provenir de la configuration (lerna.json) ou de la ligne de commande. De plus, les options de configuration peuvent vivre au niveau supérieur ou peuvent être appliquées à des commandes spécifiques.

Exemple:

{ "lerna": "x.x.x", "version": "1.2.0", "exampleOption": "foo", "command": { "init": { "exampleOption": "bar", } },}

Dans ce cas, exampleOption sera « foo » pour toutes les commandes sauf init, où il sera « bar ». Dans tous les cas, il peut être remplacé par « baz » sur la ligne de commande avec --example-option=baz.

concconcurrence

Combien de threads utiliser lorsque Lerna parallélise les tâches (par défaut 4)

$ lerna publish --concurrency 1

— scope

Étend une commande à un sous-ensemble de paquets.

$ lerna exec --scope my-component -- ls -la

$ lerna run --scope toolbar-* test

— depuis

Lors de l’exécution d’un script ou d’une commande, étendez l’opération aux paquets qui ont été mis à jour depuis le ref spécifié. Si ref n’est pas spécifié, la balise par défaut est la dernière.

Liste le contenu des paquets qui ont changé depuis la dernière balise:

$ lerna exec --since -- ls -la

Exécutez les tests pour tous les paquets qui ont changé depuis master:

$ lerna run test --since master

Liste tous les paquets qui ont changé depuis some-branch:

$ lerna ls --since some-branch

Cela peut être particulièrement utile lorsqu’il est utilisé dans CI, si vous pouvez obtenir la branche cible dans laquelle un PR entrera, car vous pouvez l’utiliser comme option ref à --since. Cela fonctionne bien pour les PR entrant dans les branches master ainsi que feature.

ignore ignore

Exclut un sous-ensemble de paquets lors de l’exécution d’une commande.

$ lerna bootstrap --ignore component-*

L’indicateur ignore, lorsqu’il est utilisé avec la commande bootstrap, peut également être défini en lerna.json sous la touche commands.bootstrap. L’indicateur de ligne de commande prendra la priorité sur cette option.

Exemple

{ "lerna": "2.0.0", "version": "0.0.0", "commands": { "bootstrap": { "ignore": "component-*" } }}

Astuce : Le glob est mis en correspondance avec le nom du paquet défini dans package.json, pas avec le nom du répertoire dans lequel se trouve le paquet.

— include-filtered-dependencies

Remarque : Cela remplacera les indicateurs --scope et --ignore.

c’est-à-dire qu’un paquet correspondant à l’indicateur --ignore sera toujours amorçable s’il dépend d’un autre paquet en cours d’amorçage.

Ceci est utile dans les situations où vous souhaitez « configurer » un seul paquet qui repose sur d’autres paquets en cours de configuration.

$ lerna bootstrap --scope my-component --include-filtered-dependencies# my-component and all of its dependencies will be bootstrapped

— loglevel

Quel niveau de journaux signaler. En cas d’échec, tous les journaux sont écrits dans lerna-debug.connectez-vous au répertoire de travail actuel.

Tous les journaux d’un niveau supérieur au paramètre sont affichés. La valeur par défaut est « info ».

maxmax-buffer

Définissez une longueur de tampon maximale pour chaque appel de processus sous-jacent. Utile par exemple lorsque quelqu’un souhaite importer un dépôt avec une plus grande quantité de commits lors de l’exécution de lerna import. Dans ce cas, la longueur de la mémoire tampon intégrée peut ne pas être suffisante.

nono-sort

Par défaut, toutes les tâches s’exécutent sur les paquets dans un ordre topologiquement trié afin de respecter les relations de dépendance des paquets en question. Les cycles sont brisés au meilleur effort d’une manière qui n’est pas garantie d’être cohérente entre les invocations de Lerna.

Le tri topologique peut entraîner des goulots d’étranglement de la concurrence s’il y a un petit nombre de paquets avec de nombreuses personnes dépendantes ou si l’exécution de certains paquets prend un temps disproportionné. L’option --no-sort désactive le tri, exécutant plutôt des tâches dans un ordre arbitraire avec une concurrence maximale.

Cette option peut également vous aider si vous exécutez plusieurs commandes « watch ». Étant donné que lerna run exécutera des commandes dans un ordre topologiquement trié, il peut finir par attendre une commande avant de continuer. Cela bloquera l’exécution lorsque vous exécutez des commandes « watch », car elles ne se terminent généralement jamais. Un exemple de commande « watch » exécute babel avec l’indicateur CLI --watch.

hoisthoist

Installe les dépendances externes correspondant à glob à la racine du dépôt afin qu’elles soient disponibles pour tous les paquets. Tous les binaires de ces dépendances seront liés dans des répertoires de paquets dépendants node_modules/.bin/ afin qu’ils soient disponibles pour les scripts npm. Si l’option est présente mais qu’aucun glob n’est donné, la valeur par défaut est ** (tout hisser). Cette option n’affecte que la commande bootstrap.

$ lerna bootstrap --hoist

Pour le contexte sur --hoist, voir la documentation du palan.

Remarque : Si les paquets dépendent de différentes versions d’une dépendance externe, la version la plus couramment utilisée sera hissée et un avertissement sera émis.

–nohoist

N’installez pas de dépendances externes correspondant à glob à la racine du dépôt. Cela peut être utilisé pour désactiver le levage pour certaines dépendances.

$ lerna bootstrap --hoist --nohoist=babel-*

— npm-client

Installe les dépendances externes en utilisant install. Doit être un exécutable qui sait installer les dépendances npm.

$ lerna bootstrap --npm-client=yarn

Peut également être configuré dans lerna.json:

{ ... "npmClient": "yarn"}

— use-workspaces

Permet l’intégration avec les espaces de travail Yarn (disponibles depuis [email protected] +).
Les valeurs du tableau sont les commandes dans lesquelles Lerna déléguera l’opération à Yarn (actuellement uniquement en amorçage).
Si --use-workspaces vaut true alors packages sera remplacé par la valeur de package.json/workspaces.
Peut également être configurée dans lerna.json:

{ ... "npmClient": "yarn", "useWorkspaces": true}

— flux

Sortie de flux des processus enfants immédiatement, préfixée par le nom du package d’origine. Cela permet d’entrelacer les sorties de différents paquets.

$ lerna run watch --stream

— parallèle

Similaire à --stream, mais ignore complètement la concurrence et le tri topologique, exécutant immédiatement une commande ou un script donné dans tous les paquets correspondants avec une sortie de streaming préfixée. C’est l’indicateur préféré pour les processus de longue durée tels que babel src -d lib -w exécutés sur de nombreux paquets.

$ lerna exec --parallel -- babel src -d lib -w

— registry

Lorsqu’elles sont exécutées avec cet indicateur, les commandes npm transférées utiliseront le registre spécifié pour vos paquets.

Ceci est utile si vous ne souhaitez pas configurer explicitement la configuration de votre registre dans l’ensemble de votre package.fichiers json individuellement lorsque, par exemple, vous utilisez des registres privés.

tagtemp-tag

Une fois passé, cet indicateur modifiera le processus de publication par défaut en publiant d’abord tous les paquets modifiés dans une dist-tag temporaire (lerna-temp), puis en déplaçant la ou les nouvelles versions vers la dist-tag par défaut (latest).

Ce n’est généralement pas nécessaire, car Lerna publiera les paquets dans l’ordre topologique (toutes les dépendances avant les dépendances) par défaut.

Assistant

Si vous préférez des conseils pour cli (au cas où vous seriez sur le point de commencer à utiliser lerna ou de l’introduire à une nouvelle équipe), vous pourriez aimer lerna-wizard. Il vous guidera à travers une série d’étapes bien définies:

Balises actuelles