-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: remove sourcehut bugstemplate #213
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, 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, 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, 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 init
results in the package.json file having abugs
URL 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.