Setup Eslint + Prettier for code standardization in React

Introduction

During the development process, it becomes important to define a project standard aimed at readability, maintenance and code quality improvement. To this end, this article will introduce two libraries that, together, allow code verification to find/solve problems and its formatting according to the defined rules.

Libs

prettier: it is the lib responsible for code formatting
eslint: it is the lib that will analyze the code with the aim of finding and solving problems

Setup

To add prettier:

yarn add prettier –dev

To add eslint:

yarn add eslint@8.57.0 eslint-config-prettier –dev

eslint@8.57.0: it will add version 8.57.0 (the latest version below 9) due to some issues related to the React plugin from version 9 onwards, which are currently being analyzed

eslint-config-prettier: it will disable the eslint rules that conflict with prettier

To add eslint plugins:

yarn add eslint-plugin-prettier eslint-plugin-react eslint-plugin-react-hooks –dev

eslint-plugin-prettier: it will allow prettier to run with eslint

eslint-plugin-react: it will include linting rules specific to React applications

eslint-plugin-react-hooks: it will include linting rules for React hooks

To allow eslint to run on a React application that uses Babel as its compiler:

yarn add @babel/eslint-parser –dev

After installing the libs, add the .eslintrc.json file at the root of the project to configure eslint execution. This file will be gradually updated as the configurations are explained:

env

It brings predefined global variables.

“browser”: true: related to the browser

“node”: true: related to the Node.js

“jest”: true: related to the Jest

For example, if I have an app that uses Jest for testing and I don’t define the env “jest”: true, when running eslint, it will raise errors like: describe, it, expect are not defined. When I set the env “jest”: true, eslint will know that these are terms used in tests and won’t raise errors because of them.

extends

It brings additional configurations for eslint.

eslint:recommended: it includes recommended rules from eslint

plugin:react/recommended: it includes recommended rules for React (this is possible due to the addition of the eslint-plugin-react plugin)

plugin:react-hooks/recommended: it includes recommended rules for React hooks (this is possible due to the addition of the eslint-plugin-react-hooks plugin)

prettier: it removes eslint rules that may conflict with prettier (this is possible due to the addition of the eslint-config-prettier lib)

parser

@babel/eslint-parser: it allows running eslint for applications that use Babel as the compiler

parserOptions

ecmaVersion: it specifies the ECMAScript syntax used (latest corresponds to the most recent supported version)

sourceType: it specifies if the application is using ESM:
module or if it’s using CommonJS: script

ecmaFeatures – “jsx”: true: it specifies if include jsx syntax

plugins

It allows adding plugins to extend eslint, which can add validation rules, configurations, envs.

prettier: prettier plugin

react: React plugin

react-hooks: React hooks plugin

settings

react – “version”: “detect”: it automatically detects the version of React used in the application

ignorePatterns

Files that will be ignored when running eslint.

*.stories.tsx: it was mentioned in the article just as an example. In this case, eslint would not check files ending with .stories.tsx

rules

Allows adding prettier rules to be executed with eslint:

prettier/prettier: it adds prettier rules when eslint is executed

error: it defines that if any prettier rule is not satisfied, it should return an error. Besides error, it’s possible to use warn, which would raise a warning if any rule is not satisfied. Or off to deactivate the rules

It allows customizing eslint rules:

“react/jsx-uses-react”: “off” e “react/react-in-jsx-scope”: “off”: disables the eslint rule that returns an error if import React from ‘react’ is not included in the files. Useful for React versions 17 onwards that don’t require this

It allows customizing prettier rules:

singleQuote: it defines single quotes as the formatting rule for strings

After finishing the configuration file setup, add the scripts in package.json:

By default, following this configuration, eslint will check .js files. To check other types of files, add after eslint in the scripts above –ext=js,{other_file_type}.

eslint .: when running yarn lint, it will check all files if they comply with eslint and prettier rules

eslint: When running yarn lint-files {file_name or folder_name}, it will check the specified file or all files in the specified folder if they comply with eslint and prettier rules

eslint . –fix: when running yarn lint-fix, it will format and correct the code according to eslint and prettier rules

eslint –fix: when running yarn lint-fix-files {file_name or folder_name}, it will format and correct the code according to eslint and prettier rules for the specified file or all files in the specified folder

Suggestion: if it’s always executed for a specific folder (for example, src), it might be convenient to replace the . in the scripts with src.

Example

Let’s start with the complete configuration file defined above:

Example file:

When running yarn lint-files for this file:

It returns 3 errors, 2 from prettier and 1 from eslint, indicating that two can be fixed by –fix:

First error: regarding the eslint rule that returns an error for declared but unused variable in the code
Second error: regarding the custom rule defined to use single quotes in prettier
Third error: regarding the prettier rule about spacing

When running yarn lint-fix-files for this file:

It fixes two of the errors that were raised and continues to report the one that was not automatically fixable. So, the file remains as follows:

Removing the unused import will eliminate any further errors appearing in the eslint execution.

Conclusion

The idea was to bring the necessary libs for configuring eslint with prettier, focusing on how to run them together and showing where it’s possible to customize the rules for both. I tried to provide a general overview of what the elements in the configuration file represent. Depending on the app, it may not be necessary to add all the elements shown above, or a small alteration may be needed in one of them. You can see the documentation version 8.57.0 of eslint for more details. In the next article, I’ll focus on bringing rules that are interesting to customize for both prettier and eslint.

Please follow and like us: