Validate package.json repository url

[adam-26]

Hi,

I was recently configuring conventional-github-releaser and it appeared to working, but no release messages were being written to github (but the tags were being created). After a while I realized this was because the wrong repository URL was set in package.json (Another repo i have access to was where the release messages were being written to).

If the repository URL configured in package.json is not the same as the git working directory, should/could a warning be displayed or error be thrown? Although this was a silly error on my behalf, such a simple check could save other users time if they were to make the same mistake.

Adam.

[hutson]

Howdy @adam-26. Thank you for filing your suggestion.

Personally, I wouldn't want to invest to much in implementing this kind of enhancement since, as you hinted at, it's an issue that can arise in pretty much any project, not just when using conventional-github-releaser.

However, I can definitely see the frustration in having this tool work, but not in the desired manner, leaving you with the burden of figuring out what happened, and why.

To help move this discussion forward, I'd like to ask you, and anyone else interested, whether we would ever expect that someone would purposefully want to have their package.json file point to a different repository than their git remote?

If not, then we would just need to see if someone already provides a validation package out there that we can just call.

[Tapppi]

@hbetts I happened to stumble across here, and yes, there are use cases for having different remotes and package.json repository fields. One of them is having a private fork (in e.g. github enterprise) of an open source project a company contributes to, thus having the private repository as your primary remote, but the open source repository configured in the package.json. I know many big companies do this, facebook is one example. They have their own private repositories and CI pipelines for open source projects, while still contributing changes to the open source version.

I personally wouldn't go presuming too much about github remotes, there's a LOT of edge cases. I'm not sure this tool would work for the example above anyway, but I would think it works for some of the edge cases at least. On the other hand this could be super useful to the majority of users, at least as a warning 😄 Just my input.

[hutson]

Thank you @Tapppi for the detailed explanation you provided for some corporate workflows. It helps to keep me informed on how individuals, teams, and companies use, or may use, tools like conventional-github-releaser and conventional-gitlab-releaser.

@Tapppi you say that we shouldn't presume too much about github remotes (I assume that means git remotes in general). Therefore, I assume switching to just getting git remote origin and using that URL as the Git host may be problematic in many edge cases?

If @stevemao is alright with it, I'd be alright with switching to a package that checked that the URLs matched, and if not, throwed an exception. (Though, I, personally, don't have the time to develop, or maintain such a package, so I would need to rely on the community to develop such a package) As y`all said, that would at least alert users, rather than erroneously publish release information, or indicate success.

[Tapppi]

Yeah @hbetts I meant git remotes in general. I don't think this is easily solvable, I don't really see git remote origin being much better than the package.json repo field and it would be a breaking change.

Optimally I think the package.json field should stay as the default and it should throw if the remote and repo field differ. You would need to be able to disable it though. The repo could be configurable as an argument, and that could squash the error. Just throwing in ideas. I'm swamped right now too, but maybe I can take a stab at it at some point.

[JaKXz]

So I just ran into this issue, and used the --verbose flag to debug and find out that I was essentially getting a 302 status from the node-github callback.

I think it makes sense to at least print the status to the console, regardless of success or failure. That way there's some feedback.

I would go a step further and say any non-200 status should print to stderr. Thoughts?