Yarn: Yarn uses matching @next / unstable version instead of latest matching stable like NPM

Created on 4 Nov 2016 · 3Comments · Source: yarnpkg/yarn

Do you want to request a feature or report a bug?
Bug 🐜 😱 Yarn selects different versions than NPM with the same version specifier.

What is the current behavior?

Package aes-decrypter is on npm: { latest: '1.0.3', beta: '1.0.0-0', next: '1.1.0' }
Package video.jsis on npm: { latest: '5.11.9', next: '5.12.6', alpha: '5.9.0-2' }
Package videojs-contrib-hls depends on aes-decrypter@^1.0.3' and video.js@^5.10.1
My package depends on videojs-contrib-hls@^3.6.7 inpackage.json:

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

No yarn.lock
Run yarn

The packages installed and added to yarn.lock are:

[email protected] (correct)
video.[email protected] (incorrect, should be 5.11.9, latest stable matching version)
[email protected] (incorrect, should be 1.0.3, latest stable matching version)

What is the expected behavior?
What NPM does with this same package.json:

Please mention your node.js, yarn and operating system version.
node.js v7.0.0
both yarn v0.16.0 and v0.19.0-0 (master at f0d875a67a06d8b2405be177d0c43820442d802b) have the bug
both npm v3.10.9 and v4.0.2 do the expected thing
macOS Sierra 10.12.2 Beta (16C32f)

Source

Ambroos

👍7

Most helpful comment

Encountered this when installing nightmare via yarn - nightmare depends on electron@^1.4.4 which resolves to 1.6.0 which is under the beta dist-tag on npm. Highest latest version is 1.4.15. I unknowingly wrote code against a beta version of electron, now need to downgrade it to run on production.

My workaround was to explicitly declare the version of electron that I wanted in package.json separately.

nfarina on 14 Feb 2017

👍5

All 3 comments

I ran into the same thing. This seems to go wrong in NpmResolve#findVersionInRegistryResponse, where range never is a key of dist-tags for transitive dependencies but simply a semver range, and config.resolveConstraint then simply returns the highest one.
(A good example of disaster striking is the horribly broken canary release mechanism of lerna, that produces semver pre-release versions that end with the short git commit hash. I guess real programmers always count downwards, and start from 'f'.)

ebednarz on 15 Nov 2016

I'm also having this problem with the typscript package.

Running npm view typescript 'dist-tags'
Gives this output:

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

Running npm install installs the 2.0.10 version
After running yarn i have this entry in yarn.lock

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

You could argue who is doing wrong. I think that yarn follows semver and looks for latest valid release which in my cases is 2.1.1.

Npm seems to use the info from dist-tags and typescript should have used the version "2.1.1-rc".