Proxying packages with GitHub Package Registry and other updates

Image of Alex Mullans

It’s been a few months since we announced GitHub Package Registry, a package management service that makes it easy to publish public or private packages next to your source code. As we’ve talked to the community, we’ve heard a few common themes. We’ve heard that ease of configuration is important, from standardizing permissions across repositories and packages to simplifying the configuration needed to use the registry from your command line. You also let us know that it doesn’t always make sense to create a release every time you publish a package. And, centralizing all of your package dependencies in one place should be a standard feature for a package manager. 

We listened to your feedback, and we’re excited to announce proxy support for the primary npm registry. We also removed the feature that automatically creates releases when you publish a package.

Introducing proxy support for npmjs.com

The npmjs.com proxy enables you to use GitHub Package Registry as the source of your organization’s npm packages and the proxied source of packages from npm. Try it out—just change the .npmrc file in your project directory (replacing OWNER with your GitHub organization or username):

Old format New format, with proxy support
@OWNER:registry=https://npm.pkg.github.com registry=https://npm.pkg.github.com/OWNER

This change tells npm to send all package requests to GitHub Package Registry, which will then serve any request for a package in your account (any package starting with @OWNER), just like it does today. It will also proxy requests for any other package to npm, so you can use packages like express or @babel/core.

We imagine this feature growing in several ways:

  • Add support for other npm sources so you can use packages from places other than npmjs.com
  • Broaden proxy support for other package types (Maven, NuGet, and Ruby)
  • Build a permanent cache on top of the proxy service to help with protection from outages

There are many possibilities with what we can do, and we’d love your feedback about what the next improvements should be. 

Take the survey

No more automatic release creation

Many customers expressed that automatically creating a release for every package published was unexpected and undesirable, and that it led to conflicts for repositories that were managing their releases closely already. As of today, publishing a package will no longer create an accompanying release. 

If you’d like to bring this functionality back, you can create a GitHub Action that triggers on the RegistryPackageEvent from GitHub Package Registry.

Using packages in Actions

We’re continuing to bring Actions and GitHub Package Registry closer together, starting with removing the need to use personal access tokens to access packages from Actions. Instead, you can use GITHUB_TOKEN when publishing or installing Maven or npm packages in a GitHub Actions workflow. We’re also introducing support for NuGet packages.

Tell us more and join the beta

As we prepare to make GitHub Package Registry generally available at GitHub Universe later this year, we want to continue to learn about your needs. Share your thoughts in our survey to get expedited access to the GitHub Package Registry beta. 

Fill out the GitHub Package Registry survey

Join us at GitHub Universe

Our largest product and community conference is returning to the Palace of Fine Arts in San Francisco, November 13-14. Hear what's next for the GitHub platform, find inspiration for your next project, and connect with developers who are changing the world.

Get tickets

GitHub Actions now supports CI/CD

GitHub Actions makes it easier to automate how you build, test, and deploy your projects on any platform, including Linux, macOS, and Windows. Try out the beta before GitHub Actions is generally available on November 13.

Sign up for the beta