Closed crissdev closed 9 years ago
Yeah, this is legitimately a bug as the //
form "looks" like a url, but is nonsense. And protocol-less urls aren't something we'd legitimately want to support anyway.
Incidentally, prior to 3.0.0, //git@github.com:npm/npm-package-arg
would return:
{ raw: '//git@github.com:npm/npm-package-arg',
scope: null,
name: null,
rawSpec: '//git@github.com:npm/npm-package-arg',
spec: '/git@github.com:npm/npm-package-arg',
type: 'local' }
Maybe doing diffs between tags might help? e.g. https://github.com/npm/npm-package-arg/compare/9aaabc2...1dc802d
FYI, I did a quick test with all versions available for this package and none of them could parse git@github.com:npm/npm-package-arg
. They all return Error: Unsupported URL Type: github.com:npm/npm-package-arg
npm: 2.1.18 node.js: 0.10.33
npa is relatively new, so if npm handled these "URLs" before (@iarna is right that these aren't really URLs), it was probably doing something different inside npm. This would be an inadvertent breaking change if that did work previously, so if you can point us to which version of npm was the last to work with these packages, that would be helpful.
[...] if you can point us to which version of npm was the last to work with these packages, that would be helpful.
@othiym23 Sorry but I don't have such information available. You may consider closing this issue since I don't see any activity on it.
Closing as resolved / irrelevant now. There have been a bunch of changes to npm recently around git, including switching to hosted-git-info
and changing how saved git URLs (and URLish things) are normalized by normalize-package-data
/ read-package-json
. You might try your test cases again and see if it still behaves in surprising ways.
I've seen packages which don't specify used protocol but the NPM registry parses correctly. For instance:
fails with
But if I add 2 slashes at the beginning then it works. The following call succeeds:
Result: