Strengthen a React Application with Github and GitHub Actions

How to make the project clean over time

Published in

Level Up Coding

5 min readApr 4, 2021

The happiness of a development team is directly proportional to the stability, cleanliness, and architecture of the project

When a project is maintained by a team, the Team Lead has the responsibility to keep it clean and safe, avoiding breaking tests, different code styles, and other bad practices that will make your project badly organized and error-prone over time.

To accomplish this goal we can use two approaches:

Manually checks: merging to the main branch only the reviewed PRs (pull requests).
Automatic checks: using a CI (Continuous integration) service like GH actions, CircleCI, i.e.

Those two methods help us to keep the application healthy for each PR avoiding merging code that is not in keeping with the application style guide.

Before understanding how we can automate the process using a CI, we should choose the instruments to make our project solid and well-maintained.

CI-related React belt kit

Here there are the libraries that I usually use to build a new React application:

These are the libraries related to the CI; there are other important libraries to build a great application like Storybook (Go to the article), TailwindCSS, WebVitals, and many others.

Few words about libraries

ESLint is a linter who can find and fix code problems, and it’s advantageous to give a global code style to the project.

Jest and Cypress are respectively a unit test framework and an end-to-end test framework. Unit tests are important to test each function and isolate responsibility. The feature test is needed to test all the puzzle pieces together, simulating the user behavior and interactions in a real browser.

Codecov is a tool that can check and store the coverage information for each pull request and push the result using GH comments.

TL;DR;

I created a complete template for both React and Express JS that you can use to start your project with a fully configurated CI:

Let’s start

Download the project

First of all, we need a complete and fully tested React application. You can FORK and clone this repository: https://github.com/vassalloandrea/react-ci

The fork is important since you need a personal Github repository to implement the CI using GH actions.

git clone git@github.com:yourusername/react-ci.git
cd react-ci

Inside that project, there are a lot of custom NPM commands that will help up running all our checks locally and on the CI.

npm run start | runs the application locally
npm run test:unit | runs the unit test using Jest
npm run test:e2e | runs the E2E test using Cypress with the GUI (only locally)
npm run test:e2e:ci | runs the E2E test using Cypress without GUI
lint | runs ESLint
lint:fix | runs the ESLint linter with the — fix option that will auto-correct all the found problems
format:check | runs Prettier
format:fix | runs Prettier with the — write option that will auto-correct all the found style issues
coverage:push | runs Codecov to push the coverage

Get familiar with these commands trying to run them.

Configure the GH repository

The best practice when you start a project is to protect the main branch avoiding you or someone else pushing directly on it. There are many reasons why it is correct to protect the main branch:

Avoiding code conflict
Add the ability to make code review sharing knowledge and reducing errors.
Add the ability to run status checks.
Deploy the application to staging each time a PR is merged into main
Enable preview deployment to test the PR fix/feature inside a dedicated environment

Protect the main branch

You can protect your branch by adding a couple of useful rules like these.

With the review rule, the PR can be merged only if one or more team members reviewed and approved the code.
With the status checks, you can tell GH that the user can’t merge the PR if one of these checks isn’t passed. A status check can be a CI workflow or another GH application (like codecov)

Implement the GH CI

The goal that we want to reach with the CI is to keep the project clean and tested over time.

To create a GH workflow, we need to create two nested directories named .github/workflows inside our project.

GH action will run all the workflows found inside that directory. Each workflow has many steps, but it’s not mandatory.

This is an example of the GH actions page with success and failure workflows.

This is a workflow detail with three different steps

Let’s create a file called ci.yml inside the .github/workflows directory. Read the comments to understand how the CI works.

The latest command runs the codecov script with a secret token. The secret token can be retrieved by creating an account and linking the GH repository to Codecov.

If you want to skip this step, for now, comment the cy.yml file from line #74 to the end.