Proxying packages with GitHub Package Registry and other updates
We’ve introduced the ability to proxy packages from the npm registry through GitHub Package Registry for easier configuration and consolidation. Read more about the change and opt in to try it out.
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.
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
Tags:
Written by
Related posts
GitHub and JFrog partner to unify code and binaries for DevSecOps
This partnership between GitHub and JFrog enables developers to manage code and binaries more efficiently on two of the most widely used developer platforms in the world.
2024 GitHub Accelerator: Meet the 11 projects shaping open source AI
Announcing the second cohort, delivering value to projects, and driving a new frontier.
Introducing GitHub Copilot Extensions: Unlocking unlimited possibilities with our ecosystem of partners
The world of Copilot is getting bigger, improving the developer experience by keeping developers in the flow longer and allowing them to do more in natural language.