Let's start configuring it.

ESLint can be configured using a .eslintrc file that lives in the root folder of the project.

To add some rules, we use the rules key.

For example, let's create a .eslintrc file and disable the semicolon:

  { 
    "rules": { 
      "semi": [2, "never"] 
    } 
  }

This configuration file needs a bit of explanation: "semi" is the name of the rule and [2, "never"] is the value. It is not very intuitive the first time you see it.

ESLint rules have three levels that determine the severity of the problem:

• off (or 0): The rule is disabled
• warn (or 1): The rule is a warning
• error (or 2): The rule throws an error

We are using the 2 value because we want ESLint to throw an error every time our code does not follow the rule. The second parameter tells ESLint that we want the semicolon to never be used (the opposite is always). ESLint and its plugins are very well documented, and for any single rule you can find the description of the rule and some examples of when it passes and when it fails.

Now, create an index.js file with the following content:

  var foo = 'bar';

If we run eslint index.js we get the following:

  Extra semicolon (semi) 

This is great; we set up the linter, and it is helping us follow our first rule.

We can enable and disable every single rule manually, or we can enable the recommended configuration in one go by putting the following code into our .eslintrc file:

  { 
    "extends": "eslint:recommended" 
  }

The extends key means that we are extending the recommended rules from the ESLint configuration, but we can always override single rules manually inside our .eslintrc file using the rules key, as we have done before.

Once the recommended rules are enabled, and we run ESLint again, we should not receive an error for the semicolon (which is not part of the recommended configuration), but we should see the linter complaining about the fact that the foo variable has been declared and never used.

The no-unused-vars rule is pretty useful for keeping our code clean.

As we have said since the beginning, we want to write ES6 (ES2015) code, but changing the code to the following returns an error:

  const foo = 'bar';

This is the error in question:

  Parsing error: The keyword 'const' is reserved

So, to enable ES6 (ES2015), we have to add the parserOptions configuration option:

  { 
    "extends": "eslint:recommended",
    "parserOptions": { 
      "ecmaVersion": 6
    } 
  }

Once we have done this, we will get the unused error again, which is fine.

Finally, to enable JSX, we use the following:

  { 
    "extends": "eslint:recommended",
    "parserOptions": { 
      "ecmaVersion": 6,
      "ecmaFeatures": { 
        "jsx": true 
      } 
    } 
  }

At this point, if you have written any React applications before and have never used a linter, a good exercise to learn the rules and get used to it is to run ESLint against the source and fix all the issues.

There are different ways in which we make ESLint help us write better code. One is what we have done until now – run it from the command line and get the list of errors.

This works, but it is not very convenient to run it manually all the time. It would be great to add the linting process inside our editor to get immediate feedback as soon as we type. To do that, there are ESLint plugins for Atom, Visual Studio Code (VSC), and the other most popular editors.

In the real world, running ESLint manually or getting the feedback live in the editor, even if it is very useful, is not enough, because we can miss some warnings or errors, or we can simply ignore them.