Explore the July edition, featuring prompts, tips, and use cases for GitHub Copilot.
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.
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|
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
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.
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.
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.
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.