Added support for detecting outdated git packages. #8300

[goloroden]

Hi @othiym23!

I have started to work on updating the outdated command so that it correctly detects outdated git dependencies. So far, things seem to work, but I am not too sure whether I got everything right. There may be a few things in the code that should be changed to better suit your way of doing things.

My primary goal so far was to show a possible way of solving this issue and to start a discussion. Maybe, if you have time, you could give me some feedback on my changes. What do you think of them? Do they head into the correct direction, or am I doing things fundamentally wrong here?

I have also added a few tests. Since they check GitHub, I needed to create a repository that has a fixed tag 0.1.0 (I need to ensure that the tags won't change, otherwise the tests break because external factors have changed).

So, I created the repository goloroden/npm-outdated-git-test. Of course it would make a lot of sense to move this repository (or something similar) to the npm organization if this PR gets merged. Then, this also means that the tests need to be adjusted. This only affects the file test/tap/outdated-git.js.

Generally speaking, thanks for your great work with npm, and I hope that I maybe can provide a (very) small bit to it :-)

Looking forward to your feedback!

Golo

[goloroden]

@zkat Since you added the needs-discussion label about 2 weeks ago and I'm not that familiar with what exactly your labels mean, I just wanted to ask whether there is anything I can help with?

[legodude17]

Why did you close this @goloroden?

[goloroden]

Well … I haven't heard anything from you within six months. One day after the PR was created, the needs-discussion label was added, and I asked in return whether there is something I can help with. I never got an answer.

To be honest, I'm a little bit disappointed.

I know that you have lots of things to do, and I know that my PR is just one of hundreds and thousands, and not a really important one - but it's just feels a little bit strange if apparently two people look at it, there is need for discussion, you politely offer help, and nobody reacts for six months. And the same is true for the issue that belongs to this PR.

Sorry for that :-(

I really do not want to be disrespectful or anything, but somehow it feels like not-being-needed.

[legodude17]

The PR looks fine to me. Though I can't approve PRs. 😄 @othiym23 and @zkat, what do you think?

[goloroden]

Please don't get me wrong. I definitely didn't want to be pushy or to upset anybody.

And if things move on now, this would be more than great :-)

Anyway, I think that there is still some fine-tuning needed, so maybe we can just do what the label needs-discussion suggests ;-). As said before, I'm glad if I can help.

[njbmartin]

This is a much needed feature for us as we are using npm outdated as a pre-commit and have a lot of private dependencies on GitHub. This would certainly make things a lot easy to flag.

I can see the difficulty being the current/wanted/latest as semver isn't supported with GitHub dependencies, but still a lot more useful than just saying "yep, it's git" and always flagging it as outdated.

[G-Rath]

What's happened with this? Reading over the comments it sounds like this feature was good to go, but still ended up being ignored for some reason?

While I understand the difficulty in trying to have npm nicely support all (re: most) potential repo flavors, it would be nice if it could at least support letting me know in someway that a git repo has a new semver tag that's dated younger (/has a higher value) than the one being used currently (when using #semver:x.y.z), since as @njbmartin said; currently npm just says 'yup it's git' and always flags it as outdated.