Feedback on npm registry v2

[tinaheidinger]

The npm registry was migrated to v2, enabling beta testers to

• have fine-grained access control over their npm packages, decoupled from the repository permissions
• have internal visibility settings for npm packages, in addition to private and public
• give permissions to packages independently for Actions and Codespaces
• publish packages on organisation level, in addition to repository level
• increase performance and maintain more package versions than earlier

Please leave your feedback as a comment!

[nicorikken]

I'm unsure if v2 is the issue or even what version of the package registry we are using, but we noticed the last couple of days that our beta npm releases get tagged with the latest tag. This breaks our processes as beta releases get used before they are released officially.

[juanibiapina]

I also tried other tags and it always publishes latest. Imagine my face when all sorts of versions were going to production :)

[ankitkaushal01]

Thanks for the feedback @nicorikken @juanibiapina. We have identified the above bug and a fix has been patched for the same yesterday. Please check is it working fine now.

[juanibiapina]

It looks like it's publishing correctly. When I do npm info <package> it shows the dist-tags correctly. On the other hand on the packages page (https://github.com/org/repo/pkgs/npm/package) it shows the latest tag on the incorrect version, different from the one in npm info.

[ankitkaushal01]

On UI, we are showing 'Latest' in v2 to a version that we recently published irrespective of tags. In V1 also, we used to show Latest Version on UI irrespective of tags.

[nicorikken]

I can confirm the same behavior. Good to have the appropriate handling of packages in the background. The handling of the latest tag in the UI is confusing to me, but this seem to be a debate in itself.

[runewizard]

Also, idk if this also related to v2 registry update, but we can't use npx calls for published packages with node 16(and npm@8). Downgrade to npm@6 mitigates this issue for us, but this is an additional overhead for our CI/CD.
Seems like metadata from registry about package comes without bin property

[NamrataJha]

Thanks @runewizard for the feedback. We have identified the above bugs and a fix has been patched for the same today.

[harrygr]

How can we get access to v2 of the npm registry? Is the beta open to organisations?

[tinaheidinger]

yes, it's open to users and organisations! you can email me your org name if you would like us to migrate it to the new version of the npm registry. tinaheidinger@github.com

[harrygr]

Thanks @tinaheidinger. I've sent you an email.

[ls-urs-keller]

Is there a way to tell if we are on v2 or not?

[tinaheidinger]

With v2, you have access to these new features:

• Before, all packages were published at repository level. In v2, they are published at organisation level, and can be linked to a repository if needed:

• Package permissions can be configured indipendently for Actions and Codespaces:

• Internal package visibility option, in addition to public and private:

[jonathanmorley]

I believe the following to be a bug in npm registry v2.

Our organization proxies GitHub Packages npm registry via Sonatype Nexus, and uses pnpm to manage our npm packages.

As of a few months ago, entries in pnpm-lock.yaml files that were previously working, suddenly started throwing 404s (for packages that are hosted in GitHub Packages npm registry).

By comparing the entries in the lockfile against the responses from GitHub packages we noticed that the download URLs for packages in GitHub Packages npm registry have changed.

As an example, @cvent/pnpm-lock-export is a package on GitHub Packages.
Running

curl -LsH "Authorization: Bearer $GITHUB_TOKEN" https://npm.pkg.github.com/@cvent/pnpm-lock-export | jq '.versions["0.4.0"].dist.tarball'

currently gives an output of "https://npm.pkg.github.com/download/@cvent/pnpm-lock-export/0.4.0/e89b43efab5f6638e42669981c268c7de8d50a13" (this filename is equal to the SHA-1 of the tarball).

In an old lockfile, this same package (@cvent/pnpm-lock-export@0.4.0) had a tarball URL of "https://REDACTED/nexus/repository/npm-public/@cvent/pnpm-lock-export/-/36a6f861ee6e85315de66965f3d773c73d793dc9270bdceb5a9a07921c47a8e3" (this filename is equal to the SHA-256 of the tarball), implying that the filename provided by GitHub Packages used to be the SHA-1 of the tarball.

When requesting the package tarball directly from GitHub Packages with the SHA-1 or the SHA-256 filename, the package is successfully downloaded.

When requesting the package tarball via Nexus, the 'authoritative' SHA-1 filename succeeds, but the 'old' SHA-256 filename throws a 404 error.

We also noticed that

curl -LvH "Authorization: Bearer $GITHUB_TOKEN" https://npm.pkg.github.com/download/@cvent/pnpm-lock-export/0.4.0/e89b43efab5f6638e42669981c268c7de8d50a13 -o /dev/null 2>&1 | grep last-modified

currently gives < last-modified: Wed, 03 Aug 2022 08:59:26 GMT, even though that package was published on 2022-07-28T15:47:41-07:00. I suspect this to be the date of the rename from SHA-256 to SHA-1, and also suspect it to coincide with a shift from npm registry v1 to v2.

I do not know whether to consider this a bug on the nexus side too, since GitHub no longer appears to be advertising the SHA-256 URL as being the tarball download URL of the package via its API, but the URL does still work.

[paul-sachs]

Does this feature cover creating a token to publish an npm package? I still can't find anything in the UI that lets me create a token to ONLY allow publishing of new packages? Or to only allow reading of packages? Maybe I'm missing something obvious but the token creation process only asks about repository access.

This change log certainly reads like it implies it's possible, but I'm starting to think that that is incorrect.