At Coveros, we have an internal initiative — Codeveros — responsible for creating and maintaining a reference application used by our training courses. Also, we use it for evaluating new tools and technologies and for any other purpose where an application or source code is needed.
Codeveros Overview
At its core, it is a microservice container-based web application. Currently, it is fronted by an Angular single-page application, with multiple single-concern Node.js REST services, and a decentralized MongoDB data persistence layer. There is a gateway service that handles common tasks such as authentication and application of security headers as well as forwarding requests to the other services. Each of the remaining services are responsible for a single model type — for example User — which connect routes (GET /user) to controller logic (getUsers()) to the data layer (users collection) for that particular model type.
When we initially created Codeveros, we wanted to create a working application as rapidly as possible. Thus, things like limiting code duplication took a back seat to working code. Many of the common tasks such as setting up the Koa and Mongoose middleware were duplicated for each service.
Once the initial proof-of-concept was achieved, it became important to pull this duplicated code out into a separate module for many reasons. First, having it in a single referenced module would make it much easier to maintain; second, it would greatly simplify the existing services; and third, it would allow us to more rapidly create new services.
We created the open source @coveros/codeveros-ms Node.js module to perform all the heavy-lifting and common functionality of our REST-based microservices. It is highly opinionated and geared to our specific requirements, but it is available for anyone to use.
For reference, the source code is available on GitHub: https://github.com/Coveros/codeveros-ms
GitHub Packages
The default location to publish Node.js modules is npm, Inc.’s public registry at https://registry.npmjs.org. Other than private options such as Nexus or other self-hosted artifact repositories, the npm registry was realistically the only public and free option. That may have changed with the introduction of GitHub Packages.
Since the initial announcement of GitHub Packages, I have been interested in exploring its features and its viability as a replacement to npm, Inc.’s public registry. The decision to create the @coveros/codeveros-ms Node.js module provided the perfect opportunity to do just that.
GitHub Packages can be used both for public and private repositories. While its usage is free and unlimited for public packages, private packages are limited by storage and data transfer limits. Private packages are billed based on usage beyond those free limts. We wanted to make @coveros/codeveros-ms publicly available, so there was no cost consideration involved with using GitHub Packages.
Publishing to GitHub Packages
In order to publish @coveros/codeveros-ms to GitHub Packages, there were a few necessary steps to perform. The specific instructions for publishing a node module are detailed here: Configuring npm for use with GitHub Packages.
In short, we needed to generate an access token with the necessary permissions, authenticate to GitHub Packages with this token, define the registry url — https://npm.pkg.github.com/Coveros — in either package.json or .npmrc, and then execute npm publish. This process is largely similar to publishing to the default registry, just with the added step of needing to specify the registry endpoint.
After successfully performing these steps, the published package will be available for download, and will be displayed alongside the source code repository
Viewing Published Packages
The below picture from the codeveros-ms GitHub repository shows that there is a single package available.
Clicking the 1 package link loads the package list page. The published @coveros/codeveros-ms node module is shown.
Clicking the codeveros-ms package title loads the package detail page. It includes both installation instructions, and various other statistics around composition and usage.
This particular package page is accessible here: https://github.com/Coveros/codeveros-ms/packages/48783
Installing Packages
The package detail page includes the command to either manually install the module, or to add it as another module’s dependency. Similar to how @coveros/codeveros-ms used .npmrc to define the publishing registry, the registry also needs to be defined when installing it. This is either done using a command-line argument or in .npmrc.
In addition to specifying the registry url, you also must authenticate to GitHub Packages. This is true even when installing public packages. Since @coveros/codeveros-ms was created as a public package, there are no specific permissions needed in order to install it beyond simple authentication.
Thoughts
It is incredibly convenient to have all software components in a single location. This not only allows casual browsing, but also enables easily traceable paths from source code to the final distributable artifacts. Further, GitHub Packages enables storing many different types of artifacts. For instance, you could both store the published node module, but also a Docker image built to run that node module. Alternative public and free registries are always appreciated.
However, the requirement to authenticate in order to download public node modules puts an unreasonable barrier in place. This is an unneeded extra step that makes it more difficult to recommend in place of the default npm public registry. When used as a private registry, or when the intention is for internal consumption only, then the burden to authenticate is lessened.
In the end, we decided to publish @coveros/codeveros-ms to the default registry in order to minimize any barriers for usage. Without any additional steps, execute npm install @coveros/codeveros to install it. The npm registry page is: https://www.npmjs.com/package/@coveros/codeveros-ms. It is very likely we will consider GitHub Packages for other uses, as our requirements align to its features.
