Yarn: Yarn usa a versão @next / unstable correspondente em vez da versão estável mais recente, como NPM

Criado em 4 nov. 2016 · 3Comentários · Fonte: yarnpkg/yarn

Você quer solicitar um recurso ou relatar um bug ?
Bug 🐜 😱 Yarn seleciona versões diferentes do NPM com o mesmo especificador de versão.

Qual é o comportamento atual?

O pacote aes-decrypter está em npm: { latest: '1.0.3', beta: '1.0.0-0', next: '1.1.0' }
O pacote video.js está em npm: { latest: '5.11.9', next: '5.12.6', alpha: '5.9.0-2' }
O pacote videojs-contrib-hls depende de aes-decrypter@^1.0.3' e video.js@^5.10.1
Meu pacote depende de videojs-contrib-hls@^3.6.7 em package.json :

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

Sem yarn.lock
Execute yarn

Os pacotes instalados e adicionados ao yarn.lock são:

[email protected] (correto)
vídeo. [email protected] (incorreto, deve ser 5.11.9, última versão estável correspondente)
[email protected] (incorreto, deve ser 1.0.3, versão mais recente de correspondência estável)

Qual é o comportamento esperado?
O que o NPM faz com este mesmo package.json:

Mencione seu node.js, yarn e versão do sistema operacional.
node.js v7.0.0
tanto o yarn v0.16.0 quanto v0.19.0-0 (mestre em f0d875a67a06d8b2405be177d0c43820442d802b) têm o bug
ambos npm v3.10.9 e v4.0.2 fazem o que é esperado
macOS Sierra 10.12.2 Beta (16C32f)

Fonte

Ambroos

👍7

Comentários muito úteis

Encontrado isso ao instalar nightmare via yarn - pesadelo depende de electron@^1.4.4 que resolve 1.6.0 que está sob a beta dist-tag no npm. A versão mais recente é 1.4.15 . Sem saber, escrevi código em uma versão beta do electron, agora preciso fazer o downgrade para rodar em produção.

Minha solução alternativa foi declarar explicitamente a versão de electron que eu queria em package.json separadamente.

nfarina em 14 fev. 2017

👍5

Todos 3 comentários

Corri para a mesma coisa. Isso parece dar errado em NpmResolve#findVersionInRegistryResponse , onde range nunca é uma chave de dist-tags para dependências transitivas, mas simplesmente um intervalo de semver, e config.resolveConstraint então simplesmente retorna o mais alto.
(Um bom exemplo de desastre é o mecanismo de liberação canário horrivelmente quebrado de lerna, que produz versões de pré-lançamento semver que terminam com o hash git commit curto. Acho que programadores reais sempre contam regressivamente e começam a partir de 'f'.)

ebednarz em 15 nov. 2016

Também estou tendo esse problema com o pacote typscript.

Executando npm view typescript 'dist-tags'
Dá esta saída:

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

Executar npm install instala a versão 2.0.10
Depois de executar o yarn, tenho esta entrada em yarn.lock

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

Você pode argumentar quem está agindo errado. Eu acho que o fio segue sempre e procura a última versão válida que no meu caso é 2.1.1.

O Npm parece usar as informações de dist-tags e o typescript deveria ter usado a versão "2.1.1-rc".