Setting Up Continuous Integration for a React Component Library With GitHub Actions

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

This lesson preview is part of the The newline Guide to Building a Company Component Library course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to The newline Guide to Building a Company Component Library, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course The newline Guide to Building a Company Component Library

Now that our component library is building, we have to find a secure way to publish our package. It's possible to lint, test, and publish our package locally, but this can be difficult to enforce with larger teams. In this module, we will be automating our publish process in a CI/CD environment. Since we're storing our repository within GitHub, we will be using GitHub actions as the CI/CD environment and GitHub packages as our private MPM registry. Both servers have a generous free tier for open source software, as well as monthly credits for private packages. Everything we're going to be doing this module will stay within the limits of the free tier. GitHub actions runs workflows based on our repository events, and for our publish workflow, we only want to run if a new MPM version has been tagged in Git, and you'll see that with Git tags with the format V version, so V1, V2, etc. To enable this workflow, let's create a new file, and that's going to be under the .github directory, and inside that let's create a new workflows folder, and we're going to create a publish.EMR file to configure this step, and let's copy this over from the course. So we're going to name this workflow publish, and we only want to run it when a new version tag is pushed to the repository, and that's going to be with the format V anything after it. We're going to have one job which is publish, and the steps for this are we're going to be checking out our code, and we're going to be setting up node with our specific version which is V16. We want to use a custom registry, in this case the MPM package registry under GitHub, and for the scope for this we actually want to modify this to match our GitHub organization or account name, so if we look at our package.json, that name that we used for the scope within the package should match what's in publish.EMR. So for me I'm going to use Ostegreen Dev, but this should be your personal account name, and then we're going to run several MPM steps to perform the publish. MPMCI is going to use our package lock.json files, that way it's a reproducible build each time it runs. We're then going to lint our code base, test our code base, build it, and then call MPM publish, and since this is ran whenever a new version tag is applied, this should have a new version to publish whenever this is ran. One nice thing about using GitHub actions is that all the node authentication is handled within GitHub actions in the workflow, so we can reference this secrets.github.token, which will ensure that whenever this is ran it has the correct authentication to publish a package for our correct scope, so everything should just work out of the box. With this added in, let's go ahead and commit our changes and push them to GitHub so that way we can see the workflow in action. And in the next lesson we're going to be publishing our component library to the private GitHub registry and consuming it within our demo style guide.