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 →

Dépannage

Ce document présente des solutions pour des problèmes que nos utilisateurs ont rencontrés par le passé lors de l'utilisation de Lerna.

Commande Import​

Problèmes de buffer pendant l'import​

Lorsque vous tentez d'importer un dépôt contenant un grand nombre de commits, il est possible que vous obteniez une erreur du type :

DeprecationWarning: Unhandled promise rejections are deprecated

ou

Error: spawnSync /bin/sh ENOBUFS during ImportCommand.execute

Solution :​

Exécutez lerna import avec le drapeau --max-buffer et spécifiez une valeur suffisamment grande (en octets). Au moment de la rédaction, la valeur par défaut sous-jacente est 10 Mo, gardez cela à l'esprit.

Impossibilité d'importer des commits de conflit de fusion​

Lorsque vous tentez d'importer un dépôt contenant des commits de fusion ayant nécessité une résolution de conflits, la commande d'import échoue avec une erreur :

lerna ERR! execute Error: Command failed: git am -3
lerna ERR! execute error: Failed to merge in the changes.
lerna ERR! execute CONFLICT (content): Merge conflict in [file]

Solution​

Exécutez lerna import avec le drapeau --flatten pour importer l'historique en mode "aplati", c'est-à-dire avec chaque commit de fusion représenté comme une seule modification introduite par la fusion.

Échec lorsque l'arborescence Git contient des modifications non validées​

Vous recevrez l'erreur fatal: ambiguous argument 'HEAD': lorsque le projet actuel comporte des modifications non validées.

Solution​

Veillez à valider toutes les modifications présentes dans votre projet Lerna avant d'importer des packages via lerna import.

Commande Publish​

Publication ne détectant pas les tags créés manuellement en mode fixe avec GitHub/GitHub Enterprise​

GitHub et GitHub Enterprise utilisent des tags Git légers lorsqu'une version est créée via l'interface web, alors que Lerna utilise des tags annotés.

Cela peut provoquer un problème où Lerna ignorera les versions précédemment publiées manuellement et étiquetées via l'interface web de GitHub.

Par exemple, si l'historique de publication est le suivant :

  • v1.1.0 publiée et taguée avec lerna publish

  • v1.2.0 publiée manuellement et taguée via l'interface web de GitHub

  • v1.2.1 publiée manuellement et taguée via l'interface web de GitHub

Exécuter lerna publish maintenant détecterait v1.1.0 au lieu de v1.2.1 comme dernière version publiée.

Les implications dépendent de votre utilisation de lerna publish :

  • L'invite de publication utiliserait v1.1.0 comme base pour les suggestions majeure/mineure/corrective.

  • Lors de l'utilisation du drapeau --conventional-commits :

    • suggérerait un incrément semver basé sur tous les commits depuis v1.1.0 (incluant ceux de v1.2.0, v1.2.1 etc.)
    • Les fichiers CHANGELOG.md générés répéteront tous les commits déjà publiés dans v1.2.0, v1.2.1 etc.

Solution :​

Si possible, privilégiez lerna publish plutôt que des publications manuelles.

Pour les nouvelles publications manuelles, utilisez git tag -a -m <version> au lieu de l'interface web de GitHub.

Pour les tags légers existants, ils peuvent être convertis en tags annotés avec une commande similaire à :

GIT_AUTHOR_NAME="$(git show $1 --format=%aN -s)"
GIT_AUTHOR_EMAIL="$(git show $1 --format=%aE -s)"
GIT_AUTHOR_DATE="$(git show $1 --format=%aD -s)"
GIT_COMMITTER_NAME="$(git show $1 --format=%cN -s)"
GIT_COMMITTER_EMAIL="$(git show $1 --format=%cE -s)"
GIT_COMMITTER_DATE="$(git show $1 --format=%cD -s)"

git tag -a -m $1 -f $1 $1

git push --tags --force

Consultez ce post Stackoverflow pour plus de détails

Publication vers un registre npm privé (Artifactory, npm Enterprise, etc.)​

Si lerna publish échoue, vérifiez la présence des éléments suivants dans votre package.json :

	"publishConfig": {
		"registry": "https://[registry-url]"
	}

Vous devrez peut-être également ajouter ce qui suit dans votre fichier .npmrc pour le(s) package(s) individuel(s) :

registry = https://[registry-url]
info

Lerna utilise toujours l'outil npm pour publier les packages, quel que soit le npmClient défini dans le fichier lerna.json. Cela signifie que toute configuration yarn ou pnpm ne sera pas détectée. Pour garantir une publication réussie vers un registre privé, assurez-vous que npm est configuré correctement avec des variables d'environnement ou un fichier .npmrc.

Débogage avec Jest / Visual Studio Code​

Il est possible de déboguer les tests Jest dans un package géré par Lerna en utilisant Visual Studio Code. Le débogage avec des points d'arrêt fonctionne avec la configuration de lancement ci-dessous dans le fichier <root>/.vscode/launch.json du monorepo. Cet exemple lance Jest pour un seul package my-package situé dans le monorepo.

{
    "name": "Jest my-package",
    "type": "node",
    "request": "launch",
    "address": "localhost",
    "protocol": "inspector",
    "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/lerna",
    "runtimeArgs": [
        "exec",
        "--scope",
        "my-package",
        "--",
        "node"
    ],
    "args": [
        "${workspaceRoot}/node_modules/jest/bin/jest.js",
        "--runInBand",
        "--no-cache",
        "packages/my-package"
    ]
}

  • --runInBand évite la parallélisation des tests sur plusieurs processus

  • --no-cache aide à prévenir les problèmes de cache

Testé avec Visual Studio Code v1.19.3 et Jest v22.1.4.