Yarn: Yarn utiliza la versión @next / instable coincidente en lugar de la última coincidencia estable como NPM

Creado en 4 nov. 2016  ·  3Comentarios  ·  Fuente: yarnpkg/yarn

¿Quieres solicitar una función o informar de un error ?
Bug 🐜 😱 Yarn selecciona versiones diferentes a NPM con el mismo especificador de versión.

¿Cuál es el comportamiento actual?

  • El paquete aes-decrypter está en npm: { latest: '1.0.3', beta: '1.0.0-0', next: '1.1.0' }
  • El paquete video.js está en npm: { latest: '5.11.9', next: '5.12.6', alpha: '5.9.0-2' }
  • El paquete videojs-contrib-hls depende de aes-decrypter@^1.0.3' y video.js@^5.10.1
  • Mi paquete depende 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"
  }
}
  • Sin bloqueo de hilo
  • Ejecutar yarn

Los paquetes instalados y agregados a yarn.lock son:

¿Cuál es el comportamiento esperado?
Qué hace NPM con este mismo package.json:

Por favor, mencione su versión de node.js, yarn y sistema operativo.
node.js v7.0.0
tanto el hilo v0.16.0 como el v0.19.0-0 (maestro en f0d875a67a06d8b2405be177d0c43820442d802b) tienen el error
tanto npm v3.10.9 como v4.0.2 hacen lo esperado
macOS Sierra 10.12.2 Beta (16C32f)

picture Ambroos
👍7

Comentario más útil

Encontré esto al instalar nightmare través de hilo: la pesadilla depende de electron@^1.4.4 que se resuelve en 1.6.0 que está debajo de la etiqueta beta dist-tag en npm. La última versión más alta es 1.4.15 . Sin saberlo, escribí código contra una versión beta de electron, ahora necesito degradarlo para que funcione en producción.

Mi solución fue declarar explícitamente la versión de electron que quería en package.json separado.

picture nfarina en 14 feb. 2017
👍5

Todos 3 comentarios

Me encontré con lo mismo. Esto parece ir mal en NpmResolve#findVersionInRegistryResponse , donde range nunca es una clave de dist-tags para dependencias transitivas sino simplemente un rango semver, y config.resolveConstraint luego simplemente devuelve el más alto.
(Un buen ejemplo de desastre es el mecanismo de liberación canario horriblemente roto de lerna, que produce versiones preliminares de semver que terminan con el hash corto de confirmación de git. Supongo que los programadores reales siempre cuentan hacia abajo y comienzan desde 'f').

ebednarz picture ebednarz en 15 nov. 2016

También tengo este problema con el paquete typscript.

Ejecutando npm view typescript 'dist-tags'
Da esta salida:

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

Ejecutar npm install instala la versión 2.0.10
Después de ejecutar hilo, tengo esta entrada en yarn.lock

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

Podrías discutir quién está haciendo mal. Creo que hilo sigue a semver y busca la última versión válida que en mis casos es 2.1.1.

Npm parece usar la información de dist-tags y mecanografiado debería haber usado la versión "2.1.1-rc".

Jontem picture Jontem en 29 nov. 2016
👍4

Encontré esto al instalar nightmare través de hilo: la pesadilla depende de electron@^1.4.4 que se resuelve en 1.6.0 que está debajo de la etiqueta beta dist-tag en npm. La última versión más alta es 1.4.15 . Sin saberlo, escribí código contra una versión beta de electron, ahora necesito degradarlo para que funcione en producción.

Mi solución fue declarar explícitamente la versión de electron que quería en package.json separado.

nfarina picture nfarina en 14 feb. 2017
👍5
¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

torifat picture torifat  ·  3Comentarios
danez picture danez  ·  3Comentarios
bouk picture bouk  ·  3Comentarios
esphen picture esphen  ·  3Comentarios
NonPolynomial picture NonPolynomial  ·  3Comentarios