Conversation
|
I think this is a compromise because some value needs to be here, |
@wraithgar Then we should fix Do you have any pointers for what about |
Currently, using https://git.sr.ht/~user/repo in `npm init` results in the package.json file having a `bugs` URL of https://todo.sr.ht/~user/repo. However, this is not how SourceHut works. An issue tracker need not exist at that URL, and often projects have issue trackers that are named differently from the repository. Therefore, no information can be inferred about the issue tracker from the git URL.
677c6ce to
2e18d3b
Compare
|
I've found the issue I think you're referring to. After applying this patch and running I'll send a |
|
Don't worry about the CI failures in node 16 et al, it's a disconnect between the npm version we're using in tests and the node version we test THIS module on. If tests pass in node 18.x we're good. |
|
|
Currently, if the bugs URL returned from `package.json`, which is processed through [hosted-git-info](https://github.com/npm/hosted-git-info), is falsy, an error is thrown. However, hosted-git-info may well return a falsy bugs URL. This can happen when there is no bugs URL in the repo, but hosted-git-info tries to infer one, but one cannot be inferred, for example if the repository URL is a SourceHut URL. This is described here: npm/hosted-git-info#213 For this reason, we should tolerate falsy URLs and fall back to whatever is defined in `bugs.js`, in this case being sent to https://www.npmjs.com/package/<packageName>.
Currently, using https://git.sr.ht/~user/repo in
npm initresults in the package.json file having abugsURL ofhttps://todo.sr.ht/~user/repo. However, this is not how SourceHut works. An issue tracker need not exist at that URL, and often projects have issue trackers that are named differently from the repository. Therefore, no information can be inferred about the issue tracker from the git URL.