Enforce JavaScript Codestyle for your React Application

Improve diff readability and code review experience


You might have used eslint before with an eslintrc file to enforce some codestyle. But did all your team-members really care about the codestyle? Maybe only your buildserver ran eslint checks and complained a little but no one really cared? And maybe you always wondered why some developers made semi-colons and others didn’t? And maybe you are somone who will really go crazy without some rules about code-style?

If you answered some or all of the questions with yes, then your pain shall be relieved now.

In this blog-post we shall configure ESLint to enforce Airbnb codestyle for a small react application. Furthermore we will configure our IDE to show us codestyle errors right away. Finally we will use some tools to automatically configure a git pre-commit hook to enforce eslint before code can be pushed to the remote repository.

Why choose the Airbnb codestyle? Well I looked at some available styles and this one really is 98% close to what I want my code to look like. Also Airbnb codestyle enforces some rules on React out of the box, so it is up to you what you use (A discussion about codestyle is off-topic for this blog-post).

Why eslint? Well there are some other tools out there like JSCSJSHint or JSLint, but it seems ESLint is the most common used one at the time of writing.

Requirements that should be met

We don’t want to enforce codestyles to annoy people, we want to enforce codestyle to have certain requirements met. These are in particular:

  • Less careless mistakes - our IDE will tell us for example to use const instead of let or that we forgot a semi-colon.
  • enforce ECMAScript 6 - Maybe you are a little old school like me and it might happen that you write function(foo) { .. } therefore your IDE will guide you to write (foo) => (…) instead.
  • Improve Diffs for Code Reviews - You also might have had some guy who committed one line of code and the diff showed the whole file as changed because of reformatted intendation. Having an enforced codestyle will prevent that from happeing and improve the readability of diffs.
  • clean and consistent Codebase - You should be able to open any JS file and should immediately be able to understand the code since it has consitent code style.
  • enforce early - Maybe you have been in some projects where linting was enforced late in the CI buildchain on the CI server? Or you needed to run it manually? And even if there were linting errors maybe developers didn’t care? I have seen it all and that’s why in my opinion it should be enforced as early as possible. Therefore our first line of defense is the IDE. The second line of defense will be a git pre-commit hook which will prevent developers from pushing code to the remote repository that does not meet the codestyle.

Demo Project and Screencast

We will perform our actions on an existing React project called Avatar Picker which had no codestyle before. You can see the code before we applied our changes in the pre-codestyle git tag.

Note that our demo-project uses webpack as build-tool and npm as package-manager. Also Babel is used on the code to build a ES5 code-bundle. The build-chain is based on essential-react which is pretty neat.

You can watch the three steps described in this blog post applied to the demo project in this screencast.


Step 1 - Install and configure ESLint

Based on the eslint-config-airbnb documentation we configure the Airbnb rules together with eslint like this.

shell:npm install --save-dev eslint-config-airbnb eslint-plugin-import eslint-plugin-react eslint-plugin-jsx-a11y eslint

Now we can run ESLint and we should see many linting errors.

shell:npm run eslint

Now we know how ESLint works. So let’s continue to setup our IDE to show us the errors directly during editing.

Step 2 - Configure IntelliJ IDEA and fix Codestyle errors

We want to tell our IDE that we want to indent with 2 spaces for js files and that our files should be UTF-8. Our line endings should be linux ones. Therefore we create a the .editorconfig file in the root folder of our project. JetBrains IntelliJ IDEA and WebStorm have EditorConfig built in so creatign the file is enough to enable it. Other IDEs have plugins for EditorConfig.


Now we need to configure IntelliJ to work with ESLint. ESLint is preinstalled in IDEA so we just need to enable it in the preferences.

IntelliJ IDEA - Enable ESLint
IntelliJ IDEA - Enable ESLint

Since the codestyle wants us to use commas at the last element of objects and arrays we disable the IDEA code inspection for that.

IntelliJ IDEA - Disable JavaScript dangling-comma inspection
IntelliJ IDEA - Disable JavaScript dangling-comma inspection

Our code level is ECMAScript 6, so let’s configure that as well.

IntelliJ IDEA - Enable ES6
IntelliJ IDEA - Enable ES6

Last but not least you should see ESLint Errors now when you open a javascript file.

IntelliJ IDEA showing ESLint errors
IntelliJ IDEA showing ESLint errors

You can watch the Video to see how I actually fix the ESLint errors. In the next step we setup an automatic git pre-commit hook to enfore eslint before developers can push to the remote repository.

Setup for Sublime Text 3

  • first install Package Control
  • Open Sublime Text and press CMD+SHIFT+P and Type Install Packages
  • Select Babel for react support and install
  • Select SublimeLinter and install
  • Select SublimeLinter-contrib-eslint and install
  • you might need to restart Sublime but it should work out of the box
Sublime Text 3 showing ESLint errors
Sublime Text 3 showing ESLint errors

Step 3 - Configure automatic git pre-commit hook

You might have heard of post-commit hooks already. These are executed on the server of the remote-repository. An example usage of a post-commit hook are GitHub Webhooks which can trigger a build after something was pushed to the repository.

Pre-commit hooks are executed locally on your cloned copy of the remote repository. The problem is, that the hooks are not cloned from the remote repository. Therefore we need a mechanism to install the pre-commit hook automatically once we run npm install.

Of course someone already thought of that and there are some tools out there to do that. I chose observing/pre-commit which is a node.js pre-commit hook auto-installer. I also ran into pre-commit by Yelp which is also pretty neat but since it is python based I choose the node.js based tool. Furthermore I don’t like global installs of external tools. Only npm is installed globally on my system and I execute all node.js binaries from ./node_modules/.bin/binaryname.

Enough theoretical jibber jabber. Let’s get to it and configure our package.json to execute the eslint script as pre-commit hook.


Now just install the pre-commit tool via npm. If your code does not reside in src folder change it to your needs.

shell:npm install --save-dev pre-commit

Windows users note:

  • Since during install a symlink is created for the hook you need an administrator cmd-window to run the npm install.
  • So if the majority of your developers use Windows you might be better of using pre-commit by Yelp


Now everytime you run git commit you will be notified of ESLint errors and are forced to fix them before pushing to the remote repository. Of course you should still run ESLint on your buildsystem as part of Continuous Integration, but now developers are forced apply the codestyle directly while writing their code.

About once or twice a month we will inform via newsletter on various topics that concern us. Subscribe to our newsletter (at bottom of page) - it’s the easiest way to get a steady insight into our activities.