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
“env“: {
“browser“: true,
“node“: true,
“jest“: true
},
}
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)
//…
“extends“: [
“eslint:recommended“,
“plugin:react/recommended“,
“plugin:react-hooks/recommended“,
“prettier“
],
}
parser
@babel/eslint-parser: it allows running eslint for applications that use Babel as the compiler
//…
“parser“: “@babel/eslint-parser“,
}
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
//…
“parserOptions“: {
“ecmaVersion“: “latest“,
“sourceType“: “module“,
“ecmaFeatures“: {
“jsx“: true
}
},
}
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
//…
“plugins“: [
“prettier“,
“react“,
“react-hooks“
],
}
settings
react – “version”: “detect”: it automatically detects the version of React used in the application
//…
“settings“: {
“react“: {
“version“: “detect“
}
},
}
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
//…
“ignorePatterns“: [“*.stories.tsx“],
}
rules
Allows adding prettier rules to be executed with eslint:
//…
“rules“: {
“prettier/prettier“: [“error“]
}
}
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:
//…
“rules“: {
“react/jsx-uses-react“: “off“,
“react/react-in-jsx-scope“: “off“,
“prettier/prettier“: [“error“]
}
}
“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:
//…
“rules“: {
“react/jsx-uses-react“: “off“,
“react/react-in-jsx-scope“: “off“,
“prettier/prettier“: [
“error“,
{
“singleQuote“: true
}
]
}
}
singleQuote: it defines single quotes as the formatting rule for strings
After finishing the configuration file setup, add the scripts in package.json:
//…
“lint“: “eslint .“,
“lint-files“: “eslint“,
“lint-fix“: “eslint . –fix“,
“lint-fix-files“: “eslint –fix“,
},
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:
“env“: {
“browser“: true,
“node“: true,
“jest“: true
},
“extends“: [
“eslint:recommended“,
“plugin:react/recommended“,
“plugin:react-hooks/recommended“,
“prettier“
],
“parser“: “@babel/eslint-parser“,
“parserOptions“: {
“ecmaVersion“: “latest“,
“sourceType“: “module“,
“ecmaFeatures“: {
“jsx“: true
}
},
“plugins“: [
“prettier“,
“react“,
“react-hooks“
],
“settings“: {
“react“: {
“version“: “detect“
}
},
“ignorePatterns“: [“*.stories.tsx“],
“rules“: {
“react/jsx-uses-react“: “off“,
“react/react-in-jsx-scope“: “off“,
“prettier/prettier“: [
“error“,
{
“singleQuote“: true
}
]
}
}
Example file:
const Example = () => <p>Eslint article</p>;
export default Example;
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:
const Example = () => <p>Eslint article</p>;
export default Example;
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.