Unable to publish to Github unless I append username to front

[Aetherinox]

Description:
Workflow scope not being detected / defaults to npm when attempting to upload to both npmjs.com and Github.

Action version:
v4

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:

• node: v20.15.0
• npm: 10.7.0

Repro steps:

• Set up a worker for pushing to both Github and npmjs (see below)

Expected behavior:
Worker should publish to both npmjs and github with the same workflow.

Actual behavior:
Created a single github workflow, it publishes to Github and npmjs

 - name: "⚙️ Setup Node"
 id: task_gpr_node_setup
 uses: actions/setup-node@v4
 with:
 node-version: '20.x'
 registry-url: https://npm.pkg.github.com/
 scope: '@aetherinox'

In the example above, I've provided the scope, as well as the Github npm repo. However, when actually running the workflow, I get:

npm error need auth This command requires you to be logged in to https://registry.npmjs.org/
npm error need auth You need to authorize this machine using `npm adduser`
npm error A complete log of this run can be found in: /home/runner/.npm/_logs/2024-07-11T08_50_52_693Z-debug-0.log

What I've noticed is that I can get Github to successfully publish my package, but I must modify my package name itself. If I change the package name to:

"name": "@aetherinox/node-toasted",

It works fine, however, if I use

"name": "node-toasted",

I get the error listed above. And after searching this git repo issue section; I've noticed quite a few are getting it, but no definitive solution. I've ensured my tokens are right, and they are. As soon as I switch the package name to include @username, then it publishes fine.

Obviously this could be a solution, but I'd prefer my packages don't start with my username on npmjs, otherwise it makes searching more complicated.

I was assuming scope is what would allow for a package name, without the need for the username at the beginning.

Here is one of the failed runs:

• https://github.com/Aetherinox/node-toasted/actions/runs/9888400127/job/27312234841

And here is the successful run:

• https://github.com/Aetherinox/node-toasted/actions/runs/9888304349/job/27311913154

For now I've removed the npmjs publish code until I can figure out how to publish to github without the name being appended to the front.

Here is the workflow file:

• https://github.com/Aetherinox/node-toasted/blob/main/.github/workflows/npm-publish.yml

A little messy with now until I get this figured out.

I did however, review the logs from the workflow, and saw this, which doesn't make sense. If it's seeing that scope, why the package name change:

Run actions/setup-node@v4
 with:
 node-version: 20.x
 registry-url: https://npm.pkg.github.com/
 scope: aetherinox
 always-auth: false
 check-latest: false
 token: ***

Also tried both scopes:

 scope: @aetherinox

 scope: aetherinox

And I tried printing /home/runner/work/_temp/.npmrc:

//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
@aetherinox:registry=https://npm.pkg.github.com/
always-auth=false

Been reading around, and someone posted using

npm init -y --scope 'scope name'

during the build process, however, it seems to cut off part of the name

name: 'node-toasted' becomes name: '@aetherinox/toasted'

[Aetherinox]

An update, hopefully you may have alternative ideas.

I assumed by using setup-node action with the scope parameter, it would take care of Github's requirement to specify a scope, so that the name could be without.

Then I attempted npm init --scope, and it was removing node from the front of the package name. Apparently that's something the developers of npm have put in place. It doesn't remove other random words, but if you put node in the package name, it strips the word all together.

So that leaves the options to simply re-name the package, or before running npm publish, doing a find and replace in the package.json file for the original package name, and changing it to start with a scope.

 - name: Find and Replace
 uses: jacobtomlinson/gha-find-replace@v3
 with:
 find: '"name": "node-toasted"'
 replace: '"name": "@aetherinox/node-toasted"'
 include: "package.json"
 regex: true

Then the package publishes successfully.

Am I missing what the scope parameter is actually for?

[v-priyagupta108]

Hello @Aetherinox,
Thank you for the detailed issue description! We will investigate the problem and come back to you with the details.

[Aetherinox]

Appreciate it. Sorry if the post is all over the place. I spent 3 hours testing every little aspect I thought could possibly fix it.

Pretty much everything I tried failed to publish the package, unless I actually edit my package.json and change the package name from:

"name": "node-toasted",

to:

"name": "@aetherinox/node-toasted",

[v-priyagupta108]

Hello @Aetherinox,
Thank you for your update.
The scope parameter in the setup-node action specifies a scope for the npm registry but does not automatically apply that scope to the package name in your package.json file.

Here’s a clearer breakdown:

• Scope Parameter: Configures the registry URL for scoped packages, directing npm to use https://npm.pkg.github.com/ for packages starting with @aetherinox/.

• Package Naming: To publish to GitHub Packages, your package must be scoped if using the GitHub registry. Prepending @aetherinox/ to your package name ensures this.

In npm, the package name in the package.json file identifies the package in the registry. If the package name does not include the scope, npm might not correctly identify it as part of the GitHub registry, defaulting to npmjs.com.

The behavior you're seeing with the npm init --scope command is a feature of npm. If "node" is in the package name, npm will remove it.

GitHub Packages only supports scoped npm packages, which have names in the format of @owner/name and always begin with an @ symbol. You may need to update the name in your package.json to use the scoped name. The GitHub Package Registry documentation explicitly states that GPR only supports scoped packages.

The workaround you found is the best solution. You can use a script or workflow step to conditionally modify the package name in package.json with a scoped version before running npm publish, or manually edit the package name to include the scope when publishing to GitHub Packages.

I hope this information helps clarify the situation. If you have further questions or issues, please feel free to share.

[Aetherinox]

Thanks for the clarification.

One more question. Github is using @scope for package names. The day I was looking into this, I read something somewhere that npmjs was debating on also using scopes, and the developer admits that it was a dumb idea to how use scopes before.

Do you know if this is being pushed on nomjs as well? I couldn't find any further information on it after I found that initial article. Because the issue is, unless I add a workflow step in to modify the package.json to automatically add the scope, that means on npmjs I have one without a scope, and then on Github, I have one with the scope added.

[v-priyagupta108]

@Aetherinox,
npm has supported scoped packages since version 2.0.0, released in October 2014. Scoped packages, identified by the @scope/name format, are used to group related packages together and to indicate ownership. This is not unique to GitHub; npm itself uses scopes to organize packages and manage permissions. While npm initially treated scoped packages as private by default, you can now publish scoped packages as public. You can find more information about npm scopes in the npm documentation.

However, the requirement to use scoped packages is specific to GitHub Packages. For npmjs.com, using scopes is optional, although it is encouraged for better organization and security.

To ensure consistency across npmjs and GitHub Packages, always use the scoped name in your package.json. This practice guarantees that the package is correctly recognized by both registries. If needed, scripts or workflow steps can be used to modify the package.json file before publishing.

I hope this provides the clarity.

[Aetherinox]

Nice, appreciate this.

The work-around via workflow seems to do good for now. At least I have a better understanding of the whole scoped situation.

Thanks for the insight.