[Case Study] GitHub Registry

What package is covered by this investigations?

The GitHub Package Registry

Describe the goal of the investigation

To figure out what should our actions be going forward. Find out how to provide a safe and sound user experience that protects against name squatting.

Should we move to the GitHub Package Registry as default registry?

I've seen this question here and there, so we probably should discuss it.

My opinion is: I don't think we need to change the default registry anytime soon, unless something changes dramatically on the npm side. There are three reasons why I think we should wait:

• The GitHub registry doesn't mirror the packages from npm afaik. So it's not a replacement for the traditional registry.

• The GitHub registry uses scopes to define which set of packages belond to it. Those scopes unfortunately conflict with the ones on npm, so switching the default would put users at risk (they would expect to download from npm, but would instead get the GitHub versions).

• I tend to have a "wait and see" policy for this kind of large-scale change. Even once we'll have figured out a way to counterbalance the two first points, we will want to make sure the GitHub registry scales properly before enabling it for everyone.

First-class support

Something we need to consider is: should the GitHub registry be one registry amongst many (in the sense that it would piggy-back on the npm: protocol), or have a first-class support (with a specific protocol, like npm+gh:)?

The first case will likely cause developer experience issues (how to depend on a GitHub package from an npm package?), the second doesn't scale very well if we need to do that for all the registries.

My perception is that we need to follow intent. For all purposes, our users will likely choose to depend on a package from one of the two sets of registry: npm or GitHub. Other registries will, I believe, merely be either 1/ mirrors of the first two, or 2/ private npm instances with specific workflows (which will be able to safely enforce the registry configuration for a given scope, for example).

In this light I'd be in favor of npm+gh: being a supported protocol (rather than just configuring the registry hostname in the settings). It wouldn't so much define the target hostname, but rather the set of packages we're expected to download.

Use a specific package from the GitHub registry instead of npm

This would become possible with the resolutions field:

{
  "resolutions": {
    "foo": "npm+gh:^1.2.3"
  }
}

Possible action points (please discuss)

• Implement a new npm+gh: protocol that would inherit from the npm registry, but would instead target the GitHub registry (probably configurable the same way as for the regular npm configuration).

• Deprecate pure semver dependencies (without protocols). Yarn v2 already supports npm:^x.y.z. Npm doesn't, but we can solve it without doing changes on their side: pure semver dependencies listed in npm packages can be defined as implicitly using the npm: protocol, while pure semver dependencies listed in GitHub packages can be defined as implicitly using the npm+gh: protocol.

• We would probably need to extend the resolutions field in order to be able to change the protocol but not the range. So something like this would become possible, which would enforce Yarn to query the package foo from GitHub without modifying its semver range:

  {
    "resolutions": {
      "foo": "npm+gh:..."
    }
  }
  

• Should we implement a yarn gh publish command (via a new plugin-github-cli plugin?) that would always send the package to the Github registry? It might be duplicate with yarn npm publish 🤔

Paging @yarnpkg/berry, @bnb, @zkochan, @clarkbw for feedback (anyone else from @GitHub interested?)