fix(resolver): Add general support for git-over-protocol URLs

[knuton]

Summary

Yarn can not handle the git+https:// dependency format correctly, as described for various versions in #1625. The problem is present in Yarn 1.2.1.

A related problem for git+ssh:// has been described in #573 and fixed in #3425.

This PR extends the solution from #3425 to use the Git fetcher for any Git-over-protocol URLs.

Test plan

Extended the package-request unit tests to verify that the correct remote type (git) is used for git+https://, while the tarball remote type continues to be used for regular HTTP(S) URLs.

[rally25rs]

Nicely done. Thanks for adding tests too! 👍

[knuton]

Nice, thanks for greenlighting.

Just realized that I checked in changes to yarn.lock. That's probably a mistake, shall I remove those?

[BYK]

Just realized that I checked in changes to yarn.lock. That's probably a mistake, shall I remove those?

I took care of that for you ;)

I feel like this logic should be merged with the one I worked on at #4657. What do you two think?

[knuton]

Thanks @BYK!

Your question prompted me to browse the Yarn codebase for a moment. Now my feeling is that this check should happen earlier, that is request.getLocked should already be called with the correct remoteType.

I just looked at some traces and I'd bet that Yarn picks the wrong resolver for certain patterns. Concretely in the project that was affected by this, Yarn looks for a resolver for the pattern multicast-dns@git+https://github.com/bnielsen1965/multicast-dns and ends up using the npm registry resolver which calls getLocked('tarball'). My familiarity with Yarn internals is too slight to tell whether the problem is with the Git resolver not claiming this, or with a pattern of this shape even getting to that point.