Badge request: GitHub Package Registry, NPM variants

[JamesMGreene]

📋 Description

Recently, GitHub has launched a new beta feature: the GitHub Package Registry (GPR)! 🎉

It currently supports alternative registries for NPM, Docker, Maven, NuGet, and RubyGems. For this issue, I would like to focus specifically on the NPM registry variant of GPR.

Ideally, Shields would support GPR support for all NPM-based badge URLs, including those that start with /npm/, /node/, /jsdelivr/npm/, /snyk/vulnerabilities/npm/, etc.

🔗 Data

As far as I know, the GitHub Package Registry for NPM supports all of the usual NPM Registry API endpoints (as it is fully compliant with the NPM CLI). This might lead one to believe that we could make use of the registry_uri query param that is available on some of the NPM services, e.g. https://img.shields.io/npm/v/@octokit/webhooks.svg?label=GPR&logo=github&registry_uri=https%3A%2F%2Fnpm.pkg.github.com (→ https://github.com/octokit/webhooks.js/packages)

However, the GitHub Package Registry's API does not support anonymous access, and so that approach fails with 404 responses.

Looking through the Shields code for the npm-base service, I see there is already support for a Bearer token, so I believe you could establish a new set of /npm-equivalent URIs for a separate instance of the npm-* services with a GitHub Personal Access Token (PAT) as the Bearer token (npm_token).

However, you may instead want to consider modifying the code to detect when registry_uri is set to https%3A%2F%2Fnpm.pkg.github.com and use an alternative secret name like gpr_token. This may feel less clean but it should still require minimal changes and would prevent the need to add and maintain alternative URLs — instead just ensuring that the support for registry_uri is available on all NPM-related endpoints.

🎤 Motivation

GitHub Package Registry is likely to become a popular alternative to the NPM registry due to its focus on security, traceability, and mandatory package @scope. If a package author chooses to publish their packages to both GPR and NPM, then they could just get badges using the existing NPM endpoints. However, if they only chose to publish to GPR, then the existing endpoints will not suffice.

[calebcartwright]

For anyone interested in taking a look at implementing this, I'd recommend leveraging the GH v4 API via our BaseGraphqlService.

Our GitHub Tag service leverages this model and serves as a good reference. l believe that the Registry Package objects, like RegistryPackageStatistics, in the GH schema would be leveraged as well

[RehanSaeed]

Please also implement other package types supported by GitHub package registry e.g. NuGet packages. This is not NPM specific.

[JamesMGreene]

@RehanSaeed I'd suggest you open new issues for the other types you care about. Their implementations will be quite different.

[calebcartwright]

@RehanSaeed I'd suggest you open new issues for the other types you care about. Their implementations will be quite different.

I'm not opposed to anyone opening up new issues, but are we sure the implementations will be different? From what I've seen, it looks like using the GitHub API via the Graph QL queries would allow us to provide the typical package badges (version, downloads, etc.) indepedently of the package type. Is that not the case?

[JamesMGreene]

@calebcartwright That might cover the absolute basics but the range of badges for NPM is substantially larger than for, e.g. NuGet:

NuGet

3 total:

NPM

37 total, though perhaps not all of them are directly relevant:

[calebcartwright]

Although I take your point, that 37 number is rather misleading @JamesMGreene 😄

Several of those badges come from entirely different services, like Snyk, jsDelivr, bundlephobia, GitHub (file), etc. which are non-applicable for Shields in relation to the GitHub Package registry. For example, we have no control over whether the Snyk service decides to integrate with the GitHub Package Registry in addition to the npmjs registry.

My point is that we need to the best thing for Shields, and not have duplicative code that has to be maintained. I suspect that we can have a single implementation that will provide Shields users with the most commonly used badges for packages hosted via GitHub Package Registry (downloads, version, and probably license) for all package types.

We can certainly also look into supporting some other npm-specific badges (like dependency version) from an npm package on GH Package Registry, which may indeed require a separate implementation. However, that does not mean we need to unnecessarily duplicate implementation for other GH package related badges for other package types.

If you'd like to scope this particular issue to just the npm-only types of badges, then we can certainly open up a new issue for core Shields support for GH Package Registry, and use this one as a tracking issue for the npm-only variants 👍

[JamesMGreene]

I'd definitely defer to any member/collaborator of the Shields project as I don't have any practical experience in the codebase, nor am I volunteering to implement these at this time. 🙇

[calebcartwright]

Sounds good! I'll open some other issues to cover the common/cross-package-type badge types, and we'll use this issue to cover the npm-only badges