Continuous Integration with Prettier + ESLint

Continuous Integration with Prettier + ESLint

Using automation to make code reviews better.

TL;DR

1. Following conventions and style are important to code readability and catching bugs.
2. We can save time during reviews by making sure our code follows conventions before submitting a change request through automation.
3. Style and errors are two different concerns. We can configure these tools to make sure that each of these concerns are taken care of:

Prettier to take care of the formatting to make it look nice.

Lynt to take care of code quality to catch bugs and enforce best practices.

Husky and Lint-Staged to auto-magically take care of these tasks.

Code reviews provide software development teams opportunities for mentorship and collaboration; they allow participants to share knowledge, and gain a deeper understanding of one another and the source code.

Admittedly, our team has spent precious review time nitpicking trivial things — such as indentation, semicolons, or using let vs const — and there’s this study that discovered 20% of code review comments are about style and best practices .

We can take back this time by preventing contributors from committing code that goes against coding conventions through automation.

Use Prettier to enforce coding style standards.

Prettier makes it simple to enforce a consistent style by reformatting your code to conform to your styling preferences. Using Prettier eliminates discussions around things such as tabs vs space, character width, etc. That savings in time and energy can be repurposed to making sure your code works, and is readable without much effort.

Prettier can be used in isolation by adding the extension in Visual Studio Code. To ensure each contributor has the same style rules applied, follow these steps to run Prettier through the CLI:

1. Install Prettier in project devDependencies:

<strong>yarn add prettier --dev --exact</strong>

2. Add .prettierrc file to the root of your project:

Use Lynt to check for errors.

If you’ve been writing JavaScript for awhile, you might be familiar with ESLint. It’s a tool developers use to perform static analysis on code to find problematic patterns, or lets you know when your code does not adhere to certain style guidelines.

The real value in ESLint is the non-style rules that prevent common errors. It can be difficult to get ESLint and Prettier to work together since sometimes their formatting rules conflict with each other.

Lyntis un-opinionated about code style, so you can rely on the best parts of ESLint (which Lynt uses under the hood) to handle error checking, and Prettier to handle concerns about style.

1. Install Lynt

yarn add lynt --dev

2. Add this script for Lynt in your package.json:

Automate these tasks with lint-staged and husky.

Finally, it can become cumbersome to have to manually check code before submitting your pull request for review. We want developers to be empowered to perform these tasks within their normal workflow, without having to think about it.

The configurations above for Prettier and Lynt can be run with a pre-commit tool to re-format staged files, and prevent a commit should the linter detect potential errors that need fixing.

1. Install husky and lint-staged:

yarn add lint-staged husky --dev

2. Add this config to your package.json:

3. Add pre-commit hook to package.json scripts:

Now, when we git commit , staged files will be auto-formatted, and will fail to commit should the linter detect any errors.

lynt error preventing commit.

In closing…

Using Lynt and Prettier together will make it easier to cross-cut concerns over code style and catching potential errors.

When automated as apart of continuous integration efforts, your team will see an increase in code consistency and early bug detection without having to think about it; allowing you to focus on less trivial things during code reviews.

Feel free to comment below, share your thoughts and ask me anything :smiley_cat: