GitHub Package Registry: Pros and Cons for the Node.js Ecosystem

The NodeSource Blog

You have reached the beginning of time!

GitHub Package Registry: Pros and Cons for the Node.js Ecosystem

Last week there was a big announcement in the developer community: the GitHub Package Registry ✨😱. In this blog post we will cover some pros and cons of the registry and the expected impact in the Node.js ecosystem.

What is a package?

A package is a reusable piece of software which can be downloaded from a global registry into a developer’s local environment and included in application code. Because packages act as reusable “building blocks” and typically address common needs (such as API error handling), they can help reduce development time. An individual package may or may not depend on other packages; for example, you may wish to use a package called foo, which depends on another package called bar. Generally speaking, installing foo would automatically install bar as well as any additional dependencies.

What is a Package Manager?

A package manager lets you manage the dependencies (external code written by you or someone else) that your project needs to work correctly.

For JavaScript, the two most popular package managers are npm and yarn.

GitHub Package Registry

GitHub Package Registry is a package management service that makes it easy to publish public or private packages and is fully-integrated with GitHub. Everything lives in one place, so you can use the same search, browsing, and management tools to find and publish packages as you do for your repositories.

Pros

  • GitHub is cooperating with npm and other services to make sure tooling and workflows are maintained. It supports familiar package management tools: JavaScript (npm), Java (Maven), Ruby (RubyGems), .NET (NuGet), and Docker images, with more tools to come.
  • It’s multi-format: You can host multiple software package types in one registry.
  • Access is entirely based on Github authentication. You can use the same credentials and permissions for both your application code and packages. Packages on GitHub inherit the visibility and permissions associated with the repository, and organizations no longer need to maintain a separate package registry and mirror permissions across systems.
  • It is possible to use Github as a private npm registry without having to create any new credentials or use new tooling.
  • Currently, the Github Package Registry is in limited-access beta and It’s free for both private and public packages during this period. Github has pledged that it will always be free for public packages and Docker images.
  • README content and package metadata will be rendered on a package listing page, like this one
  • You can set up webhook events for a package in order to be notified when it is published or updated.
  • The registry already has GraphQL and webhook support and can be used to make Github Actions, so you can fully customize your publishing and post-publishing workflows
  • It provides analytics for maintainers.
  • Ultimately, Github’s registry is backed up by Microsoft, which means it has the resources and funds to ensure ongoing maintenance.

Cons

  • Right now the registry is in limited beta, so a number of features are expected to arrive soon, but not yet available.
  • Not surprisingly, if your application code and packages all depend on Github, it becomes a single point of failure in the unlikely --but not impossible-- case that Github's own infrastructure experiences an outage or major issue.
  • When the beta period ends and the GitHub package registry becomes generally available, users will have to pay to publish and use private packages.
  • It can be confusing (and tedious) to migrate packages from other package managers.
  • GitHub only supports scoped packages for npm. e.g. npm install @nodesource/cool-package instead of npm install cool-package. So if you have non-scoped packages on npm and are considering using GitHub as your registry, the migration can be messy.
  • If you have your packages in multiple places like GitHub and npm, it’s possible that you will have different versions of the same package in both registries (with one version being slightly newer while the other is outdated). So it is a good practice to keep packages independent of the registry, or to use only one place to store your packages.

What does this mean for npm users?

npm configuration details can be found here
- If you want to install something published to Github and not npm, you will need a Github account and to authenticate with the npm client, providing an access token

What does it mean for me as a maintainer of a public npm package?

  • It could mean that you may want to publish your public packages to multiple registries, but it is not yet clear how best to do this.
  • You now have a choice for where to publish your packages between npm and github, defined by your package.json registry field.
  • The registry is compatible with npm and allows developers to find and publish their own packages, using the same GitHub interface they use for their code.

The NodeSource platform offers a high-definition view of the performance, security and behavior of Node.js applications and functions.

Start for Free