The behavior is not the same than yarn v1 when using semver ranges

[Christophe Coevoet]

When using a semver range in the package.json, it looks like this plugin checks whether the lowest bound of the semver range is outdated. yarn v1 was instead checking whether the locked version is outdated or no, which is more useful IMO (as the locked version is what actually runs in your project).

Steps to reproduce:

1. Create a package.json with a dependency on mdn-polyfills ^5.15.1 (any other package could work, it is not specific to that one. But versions numbers I give correspond to that one).
2. Run yarn install. As of writing this, this resolves to version 5.20.0 of mdn-polyfills
3. Run yarn outdated

This gives me this output:

Package                              Current   Latest    Package Type   
mdn-polyfills                        5.15.1    5.20.0    dependencies   

But the current version locked in my project is not 5.15.1.

[Mark Skelton]

Nice find, and I definitely agree that the Yarn 1 behavior seems much more correct. Out of curiosity, is there a reason you have the package version set at ^5.15.1 rather than ^5.20.0? In my experience, my package version in the lockfile and package.json often match since updating with yarn up will update both and installing new packages will install the latest.

[Christophe Coevoet]

@mskelton because my yarn.lock was generated by yarn 1 (and then migrated to yarn 2 right now as I'm trying the migration). And in yarn 1, yarn upgrade does not change the manifest (and yarn 3 is adding yarn up -R doing the same)

[Mark Skelton]

@stof Poking around this might not be as simple as I initially thought and also it would diverge from how the upgrade-interactive command checks for updated dependency version. I'm going to wait to see how Yarn 3 shakes out to determine the path forward here.