Why publish to GPR and NPM?

[fishcharlie]

File this issue is related to

In the npm-publish.yml example it has steps for publishing to both GPR and NPM. Most open source packages on NPM do not use scoped names, whereas on GPR scoped names are required.

Is there a reason to include both in this example? It seems beneficial to maybe comment out GPR or something to signify that NPM is normally the standard for open source projects.

Does GitHub recommend publishing to both NPM & GPR? If so, it makes sense to keep both uncommented. But for non scoped open source package names (which is extremely common), the example provided in that file fails. If that is the case, maybe it would be beneficial to add another step to rename the name in the package.json & package-lock.json files to a scoped name for just the GPR step?

Or is there a better way to handle this extremely common scenario? I believe the examples provided here should be as simple and easy to get started as possible, and this is a major thing I noticed when integrating this workflow, that I forgot about until I ran it.

[ethomson]

🤔 Thanks for the feedback @fishcharlie - these templates try to walk the balance between being simple examples and being useful as-is. If we lean too much on the "example" side then they'll be illustrative without actually being functional. If we lean too much on the "useful" side then they'll be dense and impenetrable, requiring lots of configuration or failing immediately.

The setup-node action should set a scope when publishing to GitHub Packages. Before we added that feature, this template did actually set the scope explicitly.

This should mean that people with a full scope on npmjs.com should be able to use this template as-is, and people who have an unscoped npmjs.com package that matches the name of their GitHub Packages packages. (That is to say that foo on npmjs.com and @username/foo on GitHub Packages should work for actions running for the user `username).

I do think that the dual-publish scenario has merit - even if not everybody wants it, this illustrates a multi-job workflow in GitHub Actions. I had intended that people would remove the section that they did not want, if there was one...

I definitely think that we could improve this experience. Could we improve the comment to elucidate this problem more indicating the way that scoping works and how to change it (by passing the scope flag). And that they can remove a publish job if they only want one...

What else could we do to improve this?

[fishcharlie]

@ethomson Thanks so much for the thoughtful reply.

I think my first question is about this scope flag. Is there a way to do that without modifying the package.json file?

My use case is for the following package:

• Repo - https://github.com/dynamoosejs/dynamoose
• Deployment yml file - https://github.com/dynamoosejs/dynamoose/blob/master/.github/workflows/publish.yml
• NPM Package - https://www.npmjs.com/package/dynamoose

My original plan was to build a step that would manually modify the package.json file before the GitHub Package Registry deployment, and not commit those changes or anything, and deploy it from there. Which seems extremely complicated, and not a good solution. But I'm unaware of any other good solution.

I do see the benefits in deploying to both NPM and GitHub Package Registry. It's kinda like a why not do both thing? But I also have reservations since maybe GitHub (especially with their purchase of NPM) might remove that scope limitation from GitHub Package Registry in the future, then I'd basically shoot myself in the foot in terms of package naming.

Obviously the goal is to have wide deployment and easy package names, and easy deployment (ideally not modifying the package.json before that one deployment).

Maybe there is just some easy method here that I'm missing. But it's hard for me to answer the question of What else could we do to improve this?, without having any solid ideas for how to improve my situation, if that makes sense.

[fishcharlie]

@ethomson After looking at this more, maybe the error I'm getting isn't related to scope like I originally thought.

I don't understand why the build below says registry-url: https://npm.pkg.github.com/ but gives an error of npm ERR! 401 Unauthorized - PUT https://registry.npmjs.org/dynamoose - You must be logged in to publish packages..

If the registry-url set in setup-node is set to GPR, why would npm publish be trying to publish to NPM?

https://github.com/dynamoose/dynamoose/runs/591000740?check_suite_focus=true

[andymckay]

Sorry, but we'd like to keep issues related to code in this repository. Thank you 🙇

If you have questions about writing workflows or action files, then please visit the GitHub Community Forum's Actions Board

If you are having an issue or question about GitHub Actions then please contact customer support

[fishcharlie]

@andymckay Totally understand. However, I'd argue this is related to the code in this repository. This is directly related to https://github.com/actions/starter-workflows/blob/master/ci/npm-publish.yml (as linked in my original issue description).

I'm still confused about why it's recommended to publish to both GPR and NPM. Why is that the default workflow? Especially for open source projects that don't have a scope (which is the majority of packages), why is this the use case?

Maybe this is a larger topic about how fragmented GPR and NPM are. But I'd argue that this file in this repo, is one of the causes or symptoms of that fragmentation.

There is no explanation I can find about why you'd want to use GPR and NPM. There is no warning that GPR only accepts scoped packages, which makes that starter-workflow almost completely useless for open source projects. However, @ethomson mentioned about how the dual publish scenario has merit. If that is the case, it doesn't seem like the workflow works very well unless it's a scoped package on both NPM & GPR. For the vast majority of use cases, this starter-workflow raises a lot more questions than it answers, and if the purpose is to use these starter-workflow's to get started quickly, this workflow does not achieve that goal.

---

@andymckay I'd ask you to please reconsider closing this issue since it is directly related to the code in this repository. Some potential actionable items here (however I still don't understand how this works so I can't advice about which would be best):

1. Comment out the GPR code by default. NPM is more popular currently. The majority of packages do not dual publish currently. So the GPR example is good for some cases, but the majority of users won't use it, so commenting it out would give the indication that it is optional.
2. Add comments to the file about why it's recommended to publish to NPM & GPR, along with scenarios where that is not recommended (ex. non-scoped open source packages (unless there is a workaround I'm missing here)). The only scenario as far as I can see where this is valid, is if you have a scoped NPM account that matches the GPR scoped name. OR maybe there is a with option you can set to manually overwrite the scope?? I'm not sure. But this is again where I get confused about why both exist. This workflow seems like it'd fail for the majority of cases currently.
3. Remove the GPR section all together. I know this is unlikely because GitHub likely wants adoption of GPR. But the reality is this workflow as it currently stands is not a useful workflow. The majority of packages are un-scoped, and GPR requires scoped packages. There is also enough information here to make it obvious that you can change registry-url to GPR to publish there.

Overall, I think this issue is actionable for code on this repo. However it started out as a question because I don't understand the why behind why this file is setup this way. So it's hard to make recommendations about potential modifications without understanding it inside and out. So that is why I was hoping my question would be answered so I could give feedback about changes to this file to make it more clear for your users.

I don't think this file makes sense as is, and I truly believe it should be modified. Just unsure what the correct/best modification here is.

[jbelien]

I don't understand why the build below says registry-url: https://npm.pkg.github.com/ but gives an error of npm ERR! 401 Unauthorized - PUT https://registry.npmjs.org/dynamoose - You must be logged in to publish packages..

If the registry-url set in setup-node is set to GPR, why would npm publish be trying to publish to NPM?

I got the same issue today !

@fishcharlie Issue has been reported (not fixed yet) here : actions/setup-node#73 ; there seems to be some workaroung, I didn't test it yet.

There is also this topic : https://git.luolix.topmunity/t5/GitHub-Actions/Why-can-t-I-publish-npm-package-to-GitHub-Packages-Registry/m-p/45964