yarnpkg/yarn

Engines check broken for nightly builds

Open

#2 172 ouverte le 7 déc. 2016

Voir sur GitHub
 (12 commentaires) (0 réactions) (0 assignés)JavaScript (2 731 forks)batch import
cat-bughelp wanted

Métriques du dépôt

Stars
 (41 514 stars)
Métriques de merge PR
 (Aucune PR mergée en 30 j)

Description

We have a package which has the following engines field:

"engines": {
  "node": ">=6.0.0",
  "yarn": ">=0.18.0",
  "npm": ">=4.0.0"
}

in package.json. As there is not yet a stable "msi" package for Windows users for installation we thought of installing the latest nightly. Unfortunately yarn does not seem to be happy with the installed version. Possibly this is because the version check is somehow flawed.

Output from installing:

yarn install v0.18.0-20161123.1451
[1/4] Resolving packages...
[2/4] Fetching packages...
error advanced-boilerplate@0.14.7: The engine "yarn" is incompatible with this module. Expected version ">=0.18.0".
error Found incompatible module
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

This seems to be a bug as v0.18.0-20161123.1451 should be successfully matched by >=0.18.0.

Guide contributeur

Direction de recherche
Étudiez la logique de comparaison semver dans la validation du moteur de yarn. Examinez comment la chaîne d'exigence du moteur est analysée et comparée à la version de yarn installée. Le problème se situe probablement dans la fonction de comparaison de version où les tags de pré version (comme ' 20161123.1451') ne sont pas correctement gérés pour l'opérateur '>='. Vérifiez l'utilisation du package npm `semver` dans la base de code, en particulier dans des fichiers comme `src/package.js` ou `src/install.js`. Considérez si la solution consiste à comparer correctement les versions de pré version en supprimant le suffixe de pré version ou en utilisant une bibliothèque semver qui prend en charge la comparaison de pré versions.
Stack technique
javascriptnodejs
Domaine
cli
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Ancienne
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GitNode.js
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
75