Yarn: Le fil utilise la version @next/unstable correspondante au lieu de la dernière version stable correspondante comme NPM

Créé le 4 nov. 2016 · 3Commentaires · Source: yarnpkg/yarn

Vous souhaitez demander une fonctionnalité ou signaler un bug ?
Bug 🐜 😱 Yarn sélectionne des versions différentes de NPM avec le même spécificateur de version.

Quel est le comportement actuel ?

Le forfait aes-decrypter est sur npm : { latest: '1.0.3', beta: '1.0.0-0', next: '1.1.0' }
Le forfait video.js est sur npm : { latest: '5.11.9', next: '5.12.6', alpha: '5.9.0-2' }
Le forfait videojs-contrib-hls dépend de aes-decrypter@^1.0.3' et video.js@^5.10.1
Mon forfait dépend de videojs-contrib-hls@^3.6.7 en package.json :

{
  "name": "yarn-next-bug-test",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "videojs-contrib-hls": "^3.6.7"
  }
}

Pas de fil.lock
Courir yarn

Les packages installés et ajoutés à fil.lock sont :

[email protected] (correct)
vidéo. [email protected] (incorrect, devrait être 5.11.9, dernière version de correspondance stable)
[email protected] (incorrect, devrait être 1.0.3, dernière version de correspondance stable)

Quel est le comportement attendu ?
Ce que NPM fait avec ce même package.json :

Veuillez mentionner votre node.js, le fil et la version du système d'exploitation.
node.js v7.0.0
les deux fils v0.16.0 et v0.19.0-0 (maître à f0d875a67a06d8b2405be177d0c43820442d802b) ont le bogue
les deux npm v3.10.9 et v4.0.2 font la chose attendue
macOS Sierra 10.12.2 bêta (16C32f)

Source

Ambroos

👍7

Commentaire le plus utile

J'ai rencontré cela lors de l'installation de nightmare via un fil - le cauchemar dépend de electron@^1.4.4 qui se résout en 1.6.0 qui se trouve sous la balise dist beta sur npm. La dernière version la plus récente est 1.4.15 . J'ai écrit sans le savoir du code contre une version bêta d'électron, je dois maintenant le rétrograder pour qu'il fonctionne en production.

Ma solution de contournement consistait à déclarer explicitement la version de electron que je voulais dans package.json séparément.

nfarina le 14 févr. 2017

👍5

Tous les 3 commentaires

Je suis tombé sur la même chose. Cela semble mal tourner dans NpmResolve#findVersionInRegistryResponse , où range n'est jamais une clé de dist-tags pour les dépendances transitives mais simplement une plage semver, et config.resolveConstraint retourne alors simplement le plus élevé.
(Un bon exemple de catastrophe est le mécanisme de libération de canary horriblement cassé de lerna, qui produit des versions préliminaires de semver qui se terminent par le hachage court de commit git. Je suppose que les vrais programmeurs comptent toujours à rebours et commencent à partir de 'f'.)

ebednarz le 15 nov. 2016

J'ai aussi ce problème avec le package typscript.

Courir npm view typescript 'dist-tags'
Donne cette sortie :

{ latest: '2.0.10',
  next: '2.2.0-dev.20161129',
  beta: '2.0.0',
  rc: '2.1.1',
  insiders: '2.0.6-insiders.20161017' }

L'exécution de npm install installe la version 2.0.10
Après avoir exécuté fil, j'ai cette entrée dans fil.lock

typescript@^2.0.9:
  version "2.1.1"
  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.1.1.tgz#41c2b64472f529331b2055c0424862b44ce58d42"

Vous pourriez discuter qui fait mal. Je pense que fil suit semver et recherche la dernière version valide qui, dans mon cas, est 2.1.1.

Npm semble utiliser les informations de dist-tags et dactylographié aurait dû utiliser la version "2.1.1-rc".