NPM public packages can't be accessed without a token

[sergioisidoro]

Container images can apparently be made public, and accessed anonymously:

A public package can be accessed anonymously without authentication. Once you make your package public, you cannot make your package private again.

https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility

However a NPM package cannon:

You need an access token to publish, install, and delete private, internal, and public packages.

https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry#authenticating-to-github-packages

This is quite confusing and counter intuitive. Why can't public NPM packages be accessed without authentication? Is this a problem of conflicting docs? I've spent a considerable amount of time trying to install a package from the NPM Github registry on a public package, but constantly got an error about missing auth token.

Am I doing something wrong, or is this by design?

[mduenias]

I want to chime in as I am experiencing the same issue.

We are publishing our component library as an NPM package in the GitHub registry.
This means all our consumer teams have to do the PAT set up locally and in their pipelines, which is even more complex when they don't use GitHub actions. So this configuration is hitting our adoption.

Having to configure the PAT hinder developer experience, specially when your package does not need to be private or requires authentication to be consumed.

I would be curious to know as well if this access gate is by design and is never going to change. So that we can take the decision to create an organisation in NPM and publish our package there.

Thanks so much!

[gerdstolpmann]

We just ran into the same issue - some of our our npm's are only containing glue code (which is quite common when you develop for WebAssembly and all the IP is in the wasm binary). It would be very useful to access these npm's without token.

[tofran]

So that we can take the decision to create an organisation in NPM and publish our package there.

In reality it is way trickier:

1. If you are publishing a package in a private registry outside NPM, like the GitHub package registry you should have an organization with the same name (scope) in the official NPM registry. This is required to avoid dependency confusion attacks.
2. If you start publishing public packages in your NPM official registry (with the same scope as you private registry), you will encounter a problem: devices configured to point to the private registry will also try to fetch public packages form there (as you can only configure the registry per scope, not package). Meaning that you are forced to also publish the public packages to the registry being used by private packages (ex GitHub).
3. Now the worst part, if developers have this configuration on their computer and generate a package-lock.json, it will have the registry hardcoded there. If you make that repository public, anyone trying to npm install will not be able to, even if all the dependencies are public, because GitHub requires an authentication token. Basically you would have to regenerate the package-lock.json.

This is quite unfortunate, I think GitHub really needs to fix it.

Hopefully I will eventually write an in-depth blog post about this.

[TheKnarf]

Not being able to install public npm packages from the Github registry without creating a personal access token makes it entirely unusable for a lot of normal use-cases...

I wish they would fix this bug.

[mayank99]

With the recent release of JSR, I think this issue deserves some attention. JSR has some interesting ideas that GitHub Packages could consider borrowing if it wants to become a serious contender.

Obviously, JSR packages are publicly installable without auth. Still, JSR is an independent registry with different packages names from the NPM registry. For compatibility with NPM, all JSR packages are hosted under the @jsr scope. This is what enables the use of JSR registry only for JSR packages, without impacting other NPM packages. (More details)

Another thing worth mentioning is the idea of "upstream sources" which Azure Artifacts uses. If GitHub Packages wants to allow mixing-and-matching of packages from the same scope hosted on different registries, this could be a good solution.

[amber-beasley-liatrio]

This has posed as a problem for our org and we are now forced to publish to npmjs instead of the GitHub npm registry so packages can be truly public (accessible as anonymous).