Yarn: Yarn is resolving modules versions incorrectly

Created on 10 Mar 2017 · 11Comments · Source: yarnpkg/yarn

Do you want to request a feature or report a bug?
I think this is a bug. I have a module in my package json ("vue-lazyload": "^1.0.0-rc12"), but when I runyarn install, yarn resolve the module to the version 1.0.0-rc9. It seems that yarn ignores the 12 and thinks the version 1.0.0-rc12 is previous to the version 1.0.0-rc9.

What is the current behavior?
To install the version 1.0.0-rc12.

If the current behavior is a bug, please provide the steps to reproduce.
Add the module "vue-lazyload": "^1.0.0-rc12" to your package json dependencies and run yarn install.

What is the expected behavior?
The expected behavior is that yarn install the module vue-lazyload with version 1.0.0-rc12 but instead is installing the version 1.0.0-rc9

Please mention your node.js, yarn and operating system version.
Node v7.7.2, yarn 0.21.3, Mac OS 10.12.3

Source

marcelombc

Most helpful comment

I agree that the tagging is not inline with the spec; however I think a lot of packages are numbered in this way and this behaviour differs from that of npm which does see -alpha10 as being newer than -alpha9.

In the interests of compatibility, would it be worth revisiting this issue?

benjie on 28 Jul 2017

👍2

All 11 comments

This is correct behavior. vue-lazyload is tagging its prereleases incorrectly -- it should be naming them e.g. 1.0.0-rc.12 (with a period) to follow the semver spec for prereleases. Otherwise, versions are sorted lexicographically. You might want to file an issue with vue-lazyload to get this fixed on their side.

billyjanitsch on 10 Mar 2017

This is correct behaviour. 1.0.0-rc12 is older than 1.0.0-rc9 according to semver, as @billyjanitsch mentioned.

Daniel15 on 11 Mar 2017

In the interests of compatibility, would it be worth revisiting this issue?

benjie on 28 Jul 2017

👍2

:+1: I second the idea of re-opening the ticket. While enforcing the spec is a great idea, yarn is aiming for painless compatibility with npm and a package published via npm which works fine when installed via npm should also be fine on yarn -- regardless of if it follows the semver spec precisely or not.

I'm guessing this is a use-case npm noticed in too many packages and then just threw it in there to handle that case.

chadfurman on 28 Jul 2017

👍1

I think people should start follow the spec for tagging, but I agreed with you @benjie. A lot of packages are numbered in this way. Some people update the package accordingly (vue-lazyload is an example), but some tend to ignore.
It would be great to have this type of compatibility.

marcelombc on 28 Jul 2017

I wonder if we can have the tools npm and yarn warn users when they publish non-spec-compliant version numbers?

benjie on 28 Jul 2017

@benjie Unless this has changed within the past few months, npm behaves identically to yarn: it sorts lexicographically, e.g. alpha10 before alpha9.

billyjanitsch on 29 Jul 2017

I wonder if we can have the tools npm and yarn warn users when they publish non-spec-compliant version numbers?

The tricky thing is that these version numbers are spec-compliant. The dot-separated pieces of the prerelease version are just alphanumeric strings. My understanding is that pieces are compared as numbers if they're entirely numeric, otherwise they're compared as strings. I could make a version 1.0.0-daniel15 and the 15 would have no semantic meaning.

this behaviour differs from that of npm which does see -alpha10 as being newer than -alpha9.

Does npm behave like that? The npm semver calculator site says that ^1.0.0-rc12 matches 1.0.0-rc9 for vue-lazyload:

Daniel15 on 29 Jul 2017

In practices, yes npm does behave like that.

Here's an example installing in a new empty directory:

$ npm install graphql-build@^0.0.1-alpha10

[...]

+ [email protected]
added 8 packages in 4.265s

There is [email protected] available which would be treated as newer than both [email protected] and [email protected] according to the semver spec, I think.

benjie on 29 Jul 2017

I believe it's the same as https://github.com/yarnpkg/yarn/issues/3560. @bestander suggested that we reuse the code here https://github.com/yarnpkg/yarn/blob/master/src/util/semver.js. I think if we use this to replace https://github.com/yarnpkg/yarn/blob/master/src/package-constraint-resolver.js#L26 it may work with preleases. Also the selective resolution feature I'm working on may also help?