`upgrade-interactive` always shows dependency installed via Git as outdated

[timm-gs]

When running the following in an empty directory:

yarn init
yarn add https://github.com/timm-gs/pixelmatch
yarn upgrade-interactive

What is the current behavior?

Yarn shows the just added package as outdated. Same behavior on future attempts after upgrading. (Does not change yarn.lock)

What is the expected behavior?

I would expect yarn to know that the package / Git repo did not change and hence not offer to upgrade it.

Please mention your node.js, yarn and operating system version.

$ git --version
git version 2.15.0

$ node -v
v6.12.0

$ yarn -v
1.3.2

$ uname -a
Darwin MacBook-Pro.local 16.7.0 Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64

[mertkahyaoglu]

I would like to work on this. I might need a little help to start.

[torifat]

Sure, feel free to ask anything 👍

[mertkahyaoglu]

@torifat Is there an easy way to know that the package's version has not been changed in the Git repo? AFAIK we use package-request module to get the outdated packages. Current behaviour is if the version is exotic for a package, we upgrade it directly, otherwise we check the registry whether the package is outdated or not, if so we then upgrade right?

[rally25rs]

@mertkahyaoglu there is some code in the file src/util/git.js that is used to figure it out during yarn install.

Specifically the functions setRef() and resolveVersion().

---

As far as I know, I think this all works by essentially running something equivelant to git ls-remote --tags --heads for the repo, which maps tags and branches to SHAs

$ git ls-remote --tags --heads
5316b3132be33a0d40fe34e4813eaa7af43b3014    refs/heads/upgrade-version-rework-3603
eb0e09b66146f90e05251ffee505734edd25f8c0    refs/heads/workspace-run-path
daefc72ff5d8e4b8e924dd29992b02eab8fce541    refs/tags/0.2.0
156c549310b83b7735aa21a978b2bbff3b44a497    refs/tags/0.3.0
ddb8bed1451bb93e82ee2291eb903248e0da5db5    refs/tags/0.4.0

and the resolved SHA is what is stored in the yarn.lock file.

There should be a way to lookup the current SHA for the resolved version and see if it is the same as what was in the lock file or not.

[ghost]

+1 any news on this? @mertkahyaoglu

[rally25rs]

4907 was submitted to change this, but that PR never passed CI tests so has just been sitting. I actually completely forgot about it.

[ghost]

Are that tests really hard to fix? I'm a newbie...

[mertkahyaoglu]

Yeah, the problem was the requests to resolve git hashes aren't made through the mocked request module. I couldn't find a way to fix the tests. Need some help over there.