Linting and formatting

Introduction

Welcome again!

In the previous article we set up the Next.js project for our blog website. If you haven't already, check it out first Getting Started.

Today we are going to focus on setting up tools which are going to help us make sure that the quality of our code is good.

I was thinking if I should do this right now at the beginning of this series of articles instead of jumping straight into building features for our blog. The reason I am doing this now is that I think, the earlier we provide ourselves tools to bring consistency in our code, the better. If we start to add these tools later, we can get a headache of the amount of warning and errors spitted by the ESLint or Prettier when they check a long list of our files we have created.

Before we move forward, we want to create a branch for the changes we are about to make, so when we are done we can commit and push the changes to this branch and then open a pull request.

Setting up Prettier

Prettier is a tool which is responsible for keeping our files formatting consistent. There is long list of configurations, which you can use to format files anyway you like. Please check the official documentation to learn more about the tool.

We are not going to go that far tho. For our purposes (and honestly in most cases), we are going to keep just some basic configuration.

Installation

To install prettier, we are going to simply do:

This command will install Prettier as development dependency.

After that, in our project root directory, we create file.

Here is what we are putting inside that file:

These are the settings I am using in most of my projects, but you can set in here anything you like and what matches your preferences.

I think it does not matter that much as it keeps all the files the same. If you are working on a team project, these settings definitely should be discussed, so everyone is happy with them. The same is true about all the other linting configurations we are going to set up today.

Setting up ESLint

ESLint is a tool which enforces our code quality. To do so we are setting up rules we want our code to follow and then let ESLint check our code for problems, and even fix some problems which it knows how to fix. Same as in case of prettier, there are a lot of different configurations you can use. To find our more about what can be done with ESLint, please check out the documentation.

Updating ESLint configuration

ESLint, in contrast to prettier, is already installed and pre-configured as it is a part of Next.js project installation.

We are just going to extend the configuration to integrate it with Prettier and also with TypeScript.

We need to install all the necessary packages first.

Once this is done, we now open our , but before that lets change this file to . Now we can put in the configurations we are going to use.

We can now use terminal to run both ESLint and Prettier to check and fix all the files in our project. To do so we can use npx.

First command runs ESLint against all the and files in our directory. The second one runs prettier on all the files in our project. After that we are sure that all our files have consistent formatting and are following the code standards we have set with ESLint.

We can also check if our project builds without any errors by running .

Everything seems to be fine. This means we can add two more tools which are going to make sure that every commit we make is being checked before.

Husky and Lint-staged

Husky is a tool which allows running different code checks on commit. Only if all the checks pass, the commit is successfully performed. This ensures we are not even committing anything what does not meet our standards.

Installing Husky

All the steps we need to perform to properly set up Husky are described on the project's website.

To start we need to install Husky in our project.

Next we can initialize Husky in our project by running:

This has created directory in root directory of our project with all the files we can use to add hooks to different git events. The only one we care about is , but first let's set up Lint-Staged.

Setting up Lint-Stage

Again, all the information about installation and configuration can be found in the documentation.

To install Lint-Staged in our project we need to run:

Now we need to create a configuration file. Let's create with following configuration:

Look at the comments in the code to understand the configuration.

Trying things out

Now we should have all the linters and other tools set up correctly. To confirm if everything is fine we just have to try committing our changes.

As soon as we run the we now can see all the code checks running for us. This is great because now we can be sure, we are not pushing any changes to our project, which does not meet our standards.

BTW with commit messages we are going to follow conventional commits guide.

Opening pull request

Now when we have committed the changes to the branch we created, we have to open a pull request on GitHub, to get these changes merged back to the main branch. Maybe this is too much for a project which is run by only one person, but again, this is a good habit. The other benefit we can get from it, even if we are the only contributor, is setting up some GitHub actions to run various code checks and tests for us, to make sure that the changes we want to merge back to the production branch, are not going to break anything. We will come back to this topic when we will be setting up testing environment.

So, in the previous changes we already published the branch to GitHub and pushed all the changes to it. Now let's open your repository page on GitHub. On the main repository page, we should see something like this:

When we click on the Compare & pull request button, we will be moved forward to the pull request creation form. This prompt is not always visible there, on the main repository page. The other way to open a pull request is by clicking on the Pull requests button in the header of the web page. This will take us to the page where all pull requests are listed. In our case this page is empty but what we are interested in now is the green button saying New Pull request.

In the pull request form, we first have to select the source and target branches, where source is the branch we have created and pushed our changes and target is our main branch.

After that we just click Create pull request button, and now we can further configure the pull request. In our case we won't do anything more than what we have for the sake of simplicity. Let's just click the Create pull request button.

Now we have our pull request and can merge it back to master. We don't have any checks to run on the changes to check them further, but we have tested our changes locally. Before we click the green merging button, I recommend first clicking on the arrow on its right side and select Squash and merge. This will squash all our commits together (if we have nore than one in our PR) and then merge them to the target branch. After selecting the before mentioned option we can now click on Squash and merge.

After than let's also delete the branch as we are not going to use it anymore, by clicking the Delete branch button which appeared after merging. I recommend to you to set automatic deletion of branches as described in this documentation. I will also do it in our course repository.

Please remember these steps as I am not going to describe them anymore in this course.

Summary

We are almost done here - all the changes are pushed and merged. The last thing we should do now is to do some cleanup in our project locally. We need to check out the main branch, pull the changes and delete the local branch we were using.

And this is it! We now have our linters set and ready to test each of our commits in the future. How cool is that?

See you soon n the next part! Creating an articles service