馃敟 Efficient workflow with ESLint and Prettier
- Published on
I have a few tools which I use consistently across JavaScript projects I work on. ESLint and Prettier are in the top 5. Whereas Prettier is used to autoformat my code to enforce an opinionated code format, ESLint makes sure to keep my code style in a good shape. This way I don't have to worry about code formatting anymore.
In this post, I'll share some plugins and config I use for enforcing a standard style guide.
Installing things
First things first, we'll install eslint
and prettier
as dev dependencies.
npm install -D eslint prettier
Then create .prettierrc.js
and .eslintrc.js
file to configure options related to each tool.
If you use VSCode, I'd recommend using Prettier and ESLint. These extensions highlight issues in the editor, so it's easier to spot them when writing code instead of pulling out your hair later when you accidentaly commit 馃挬 code.
The Plugins
Following are the plugins which I currently use:
"eslint-config-airbnb"
: This package provides Airbnb's .eslintrc as an extensible shared config."eslint-config-prettier"
: Turns off all rules that are unnecessary or might conflict with [Prettier]."eslint-plugin-import"
: This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, and prevent issues with misspelling of file paths and import names."eslint-import-resolver-alias"
: a simple Node.js module import resolution plugin foreslint-plugin-import
, which supports native Node.js module resolution, module alias/mapping and custom file extensions."eslint-plugin-jsx-a11y"
: Static AST checker for accessibility rules on JSX elements."eslint-plugin-prettier"
: Runs Prettier as an ESLint rule and reports differences as individual ESLint issues.
For projects which use React, (like Gatsby and Next.js)
"eslint-plugin-react"
: React specific linting rules for ESLint"eslint-plugin-react-hooks"
: This ESLint plugin enforces the Rules of Hooks."eslint-plugin-testing-library"
: ESLint plugin to follow best practices and anticipate common mistakes when writing tests with Testing Library
The Config
I use .prettierrc.js
and .eslintrc.js
to manage configurations for JavaScript based projects.
module.exports = {
tabWidth: 2,
semi: true,
singleQuote: true,
jsxSingleQuote: true,
bracketSpacing: true,
jsxBracketSameLine: false,
arrowParens: 'always',
}
The prettier config is self-explanatory. Visit the docs if you wanna know all the options prettier provides.
module.exports = {
env: {
browser: true,
es2021: true,
node: true,
jest: true,
},
extends: [
'eslint:recommended',
'plugin:react/recommended',
'airbnb',
'plugin:prettier/recommended',
],
parserOptions: {
ecmaFeatures: {
jsx: true,
},
ecmaVersion: 12,
sourceType: 'module',
},
plugins: ['react', 'testing-library'],
settings: {
react: {
version: 'detect',
},
'import/resolver': {
alias: {
map: [
['@/components', './src/components/'],
['@/services', './src/services/'],
['@/context', './src/context/'],
['@/utils', './src/utils/'],
],
extensions: ['.js', '.jsx'],
},
},
},
rules: {
// NextJs specific fix: suppress errors for missing 'import React' in files for nextjs
'react/react-in-jsx-scope': 'off',
// ignore prop types valdation,
'react/prop-types': 'off',
// NextJs specific fix: allow jsx syntax in js files,
'react/jsx-filename-extension': [1, { extensions: ['.js', '.jsx'] }], // should add ".ts" if typescript project
// error out formatting not matching prettier rule
'prettier/prettier': ['error', { singleQuote: true }],
},
}
Couple of note-worthy things here:
- I use
airbnb
standard linting rules, and override rules specific to the project I work on in therules
section - The
import/resolver
setting is to map the path alias and let the linter know that it's a valid path, else you'll getUnable to resolve path to module 'xyz' (import/no-unresolved)
error.
I also use a jsconfig.json
to avoid the import path hell. So instead of importing something from ../../../components/Button
, I simply write @/components/Button
. And this works on any level of nested folders.
{
"compilerOptions": {
"baseUrl": "src",
"paths": {
"@/components/*": ["./components/*"],
"@/services/*": ["./services/*"],
"@/context/*": ["./context/*"],
"@/utils/*": ["./utils/*"]
}
}
}
I like to keep all files neatly tucked in the src
folder, hence the baseUrl: "src"
. After that, for each folder, I add an alias prefixed with @/
.
Bonus: VSCode Settings
I am a WebStorm user. But I do use VSCode when I want to do a quick PR review, or some minor tasks which doesn't require a full-blown IDE.
In order to get Prettier, ESLint and VSCode to behave properly with each other, I modify a couple of VSCode settings.
{
"files.autoSave": "onWindowChange",
"editor.formatOnSaveMode": "modifications",
"editor.formatOnSave": true,
"[javascript, javascriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
}
The configurations translate to:
- Auto Save when VSCode window loses focus, i.e I switch to another window.
- When the file is saved, apply formatting only to the modified lines instead of the entire file.
- Format the file when the file is saved.
- Use Prettier Extension to format JavaScript files.
That's it. The configuration files for Prettier and ESLint can be adjusted to your needs. Prettier provides just a handful of configuration to work with, but ESLint leaves everything upto you. You can start from scratch, or use configurations from standards like airbnb
and adjust the rules as per your needs.
I follow the naming convention of
@/
to denote package is from a local directory and not an installed module.