By Carlos Santana on
Reading time: 3 minutes


Airbnb React/JSX Style Guide is the most popular style guide for coding in React. In this post, I'll explain to you how to implement ESLint with the Airbnb React/JSX Style Guide rules.

Getting ready

In order to implement the Airbnb React/JSX Style Guide, we need to install these packages:

npm install --save eslint eslint-config-airbnb eslint-plugin-babel eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react eslint-plugin-standard

I don't like to force anyone to use a specific IDE, but I would like to recommend some of the best editors to work with React.



In my personal opinion, Atom is the best IDE for working with React. For this example, we are going to use Atom.


  • MIT License (open source)
  • Easy to install and configure
  • Has a lot of plugins and themes
  • Works perfectly with React
  • Support for Mac, Linux, and Windows
  • You can use Nuclide to React Native (


  • It's slow compared with other IDEs (if you have 8 GB of RAM you should be fine)

Visual Studio Code (VSC)


VSC is another good IDE for working with React.


  • MIT License (open source)
  • Easy to install
  • It has a lot of plugins and themes. Works perfectly with React
  • Support for Mac, Linux, and Windows


  • Microsoft (I'm not a big fan of Microsoft) 
  • Configuration can be confusing at the beginning

ESLint Rules

There are some rules of Airbnb React/JSX Style Guide that I prefer not to use or change the default values a little bit, but it depends whether you keep them or remove them.

You can check all the ESLint rules on the official website ( and all the special React ESLint rules at

The rules that I prefer not to use or I prefer to change the default values of are as follows:

  • comma-dangle: off
  • arrow-parens: off
  • max-len: 120
  • no-param-reassign: off
  • function-paren-newline: off
  • react/require-default-props: off

Now you need to create a file called .eslintrc at the root level. 

  "parser": "babel-eslint",
  "extends": "airbnb",
  "rules": {
    "arrow-parens": "off",
    "comma-dangle": "off",
    "function-paren-newline": "off",
    "max-len": [1, 120],
    "no-param-reassign": "off",
    "react/require-default-props": "off"
File: .eslintrc

Finally, you need to add a new script to run the linter rules:

"scripts": {
  "start": "react-scripts start",
  "build": "react-scripts build",
  "test": "react-scripts test",
  "eject": "react-scripts eject",
  "lint": "eslint --ext .jsx,.js src"
File: package.json

Then go to your terminal and run the command: npm run lint. You will see a lot of errors, something like this: 


Running ESLint on Atom

The linter validation is very important for any project. Sometimes, this is a topic of discussion because most developers do not like to follow standards, but once everyone gets familiar with this style guide everything is more comfortable, and you will deliver better quality code.

So far, we know how to run the linter validation in the terminal, but you can also add the ESLint validator to your IDE (Atom and VSC), in this example we will use Atom.

In Atom (on Mac) you can go to Preferences > +Install, and then you can find the Atom plugins. I'll give you a list of the plugins I use to improve my IDE and increase my productivity.

  • linter-eslint: Lint JS on the fly, using ESLint
  • editorconfig: Helps developers maintain consistent coding styles between different editors
  • language-babel: Supports React syntax
  • minimap: A preview of the full source code
  • pigments: A package for displaying colors in projects and files
  • sort-lines: Sorts your lines
  • teletype: Shares your workspace with team members and allows them to collaborate on code in real time

Once you have installed these, packages if you go to a file with lint errors, you will be able to see them: 


Configuring EditorConfig

EditorConfig is also very useful for maintaining consistent coding styles when people in our team uses different editors. EditorConfig is supported by a lot of editors. You can check whether your editor is supported on the official website,

The configuration I use is this one; you need to create a file called .editorconfig in your root directory:

root = true

indent_style = space 
indent_size = 2
end_of_line = lf
charset = utf-8 
trim_trailing_whitespace = true 
insert_final_newline = true

indent_size = 4

trim_trailing_whitespace = false
File: .editorconfig

You can affect all the files with [*], and specific files with [*.extension].


Running the linter validation in our IDE or with the Terminal is not enough to be sure that we are going to validate 100% of our code, and we are not going to inject any linter errors into our Git repositories. The most effective way to be 100% sure we are sending validated code to our Git repositories is to use Git hooks. That means you run the linter validator before performing a commit (pre-commit) or before a push (pre-push). I prefer to run the linter on the pre-commit and the unit tests on the pre-push.

Husky is the package we are going to use to modify our Git hooks; you can install it with this command:

npm install husky

Once we have added this package, we need to alter our package.json and add new scripts:

Only members can see all the codes
You can Login or Sign Up

File: package.json

In this case, in our pre-commit, we will run our linter validator, and if the validator fails, the commit will not be executed until you fix all the linter errors. The post-merge and post-rewrite hooks help us to sync our npm packages, so for example, if User A adds new npm packages, then User B pulls the new code and will automatically run the npm install command to install the new packages in the User B local machine.

You can always skip the git hooks with two commands:

  • To skip pre-commit: git commit -nm "The message of your commit"
  • To skip pre-push: git push origin <your-feature-branch> --no-verify
avatarLeave a comment

Your comment

Only members can comment. You can Login or Sign Up