Consider this fragment from a package.json:
Because this url ends in ".git", rather than treating this as a tarball instead treat it as a git repository. This would augment GitHub URLs to also allow for private Git repositories, GitHub Enterprise, etc.
You can currently do that with any of these as the value
This could be a good point for discussion: is assuming a dependency whose location begins with an HTTP URI scheme is a tarball too magic?
Should we consider file extensions, then attempt git+https ourselves on a URI that ends in .git?
It might be a good idea unless I'm overlooking some technical reasons for how we currently do things. Either way, the functionality you're looking for exists now, even if this could be a nice change in the future.
I agree: assuming it's a tarball is too magic. I'd further suggest that tarball is likely not a frequent use-case, and transitioning tarballs away from purely a url to perhaps tar+https://someurl.com/path/to/ball.tar.gz makes the intention more clear.
A lot of this has to do with how npm handles dependencies normally (via a tarball from the registry). So tarballs aren't going away anytime soon or getting handled as a second class citizen, but maybe someday there can be magic support for other file extensions.
If you like magic, it is possible to mimic git behaviour and check if a remote application supports git protocol with one separate request. For example, it can be used as a fallback after tarball download fails.
curl -D - https://github.com/isaacs/npm.git/git-upload-pack -X POST \
-H 'Content-Type: application/x-git-upload-pack-request' \
-H 'Accept: application/x-git-upload-pack-result' \
-H 'User-Agent: git/22.214.171.124'
HTTP/1.1 200 OK
Date: Thu, 31 Oct 2013 05:13:59 GMT
Expires: Fri, 01 Jan 1980 00:00:00 GMT
Cache-Control: no-cache, max-age=0, must-revalidate