Yarn: L'ajout d'une nouvelle dépendance ne respecte pas la contrainte de version existante dans la résolution
Voulez-vous demander une fonctionnalité ou signaler un bogue ?
Bogue.
Quel est le comportement actuel?
Yarn n'honore pas les verrous de version déjà ajoutés lors de la résolution des dépendances des dépendances nouvellement ajoutées.
Si le comportement actuel est un bogue, veuillez fournir les étapes à reproduire.
- Initier un module vide
- Ajouter réagir 15.6.1
yarn add [email protected] - Ajouter [email protected]
yarn add [email protected] - Le bogue se reproduit et deux versions réagissent différentes sont installées:
$ yarn list react
yarn list v1.1.0
├─ [email protected]
└─ [email protected]
└─ [email protected]
✨ Done in 0.24s.
Quel est le comportement attendu?
Ne devrait être installé que yarn.lock après que les deux dépendances sont dans le package.json et yarn install ie
$ rm -rf node_modules/ yarn.lock && yarn install && yarn list react
yarn list v1.1.0
└─ [email protected]
✨ Done in 0.17s.
Veuillez mentionner votre node.js, votre fil et la version de votre système d'exploitation.
$ node --version
v6.9.4
$ yarn --version
1.2.0
$ system_profiler SPSoftwareDataType|grep "System Version"
System Version: macOS 10.12.6 (16G29)
EDIT: La reproduction originale a été faite avec du fil v.1.1.0, mais j'ai mis à niveau vers la version 1.2.0 et cela se reproduit toujours.
hniirane
Tous les 4 commentaires
Je fouille dans ça ...
Remarquer que les paramètres passés à PackageResolver.getHighestRangeVersionMatch(name, range, manifest) peuvent être incorrects. Le range passé semble être la version unique résolue réelle ( 15.6.2 ) au lieu de la plage demandée ( ^15.5.4 ).
Cela s'accumule à son tour jusqu'à la ligne où il vérifie si des versions installées actuelles correspondent à la plage semver: semver.maxSatisfying(["15.6.1"], '15.6.2'); // null Si la plage correcte avait été passée, alors il aurait exécuté semver.maxSatisfying(["15.6.1"], '^15.5.4'); // 15.6.1 ce qui devrait résoudre ce problème.
Je vais continuer à revenir en arrière dans le code ...
rally25rs
le 11 oct. 2017
OK, il semble que cela a été introduit par # 3729 spécifiquement la ligne dans package-request.js :
const solvedRange = semver.validRange(range) ? info.version : range;
Donc, si la plage ( ^15.5.4 ) est valide, alors nous utilisons info.version place ( 15.6.2 ).
Cela est transmis pour voir si des versions installées correspondent à 15.6.2 :
const maxValidRange = semver.maxSatisfying(['15.6.1'], '15.6.2'); // null
@arcanis, il semble que ce PR lié était le vôtre. J'hésite à changer quoi que ce soit et à risquer de rouvrir tout ce que le PR a fixé. Pouvez-vous donner un coup de main?
rally25rs
le 11 oct. 2017
Je vais examiner cela aujourd'hui 👍
arcanis
le 16 oct. 2017
Sooo, essayons de résoudre ce problème! Je n'aime pas que les paquets reposent sur le levage (notez mes mots - même si nous corrigeons cela, ils se casseront à nouveau dans le futur), mais le rendre moins efficace qu'il ne pourrait l'être n'est pas non plus génial. Republier ce que j'ai mis sur # 5561:
Je ne comprends pas vraiment la logique ci-dessus. si range est un semver valide, ne l'utilisez pas?
Vous avez raison, cela n'a pas beaucoup de sens: / Je pense que ce que je voulais faire était "si ce n'est pas une version mais une gamme, alors utilisez celle que nous avons déjà si possible" (puisque le but du PR était de ne pas faire d'optimisation lors de la lecture du fichier de verrouillage). En tant que tel, la condition devrait probablement être:
const solvedRange = semver.valid(range) && !semver.validRange(range) ? range : info.version;
Questions connexes
sebmck
·
3Commentaires
MunifTanjim
·
3Commentaires
chiedo
·
3Commentaires
esphen
·
3Commentaires
AzGoalie
·
3Commentaires
Commentaire le plus utile
Je vais examiner cela aujourd'hui 👍