ESLinter is a linting tool, and I won't limit my answer to ESLint, but try to explain to you why linters are useful in general.

What is a "linter"?

A linter is a tool, which tests source code against a given ruleset and returns any validations.

Example: You input a rule which states that the code has to be indented with 4 spaces, however, by accident, some (not all) of the indentations in the source code use tabs. The linter will return all tabs as errors, which might be visually displayed in an editor or IDE, prevent further build steps and fail CI tests.

Why is a linter useful?

Linters have two major benefits. The one above is stylistic, which unifies the way a team works together. In the editor, in which the source was written, the circumstance that there are mixed whitespaces and tabs might not be visible at all, so no problem. The disaster will only start when the source code is viewed in a different editor (for example by a different dev with their own favorite editor) or even pasted online. The tabs will have a different width than the spaces and the source code will be hard to read or indentation level might even be mistaken, since whitespaces and tabs are both invisible.

The second use-case is preventing bugs. I know, that there are certain people who like to drop semicolons, so let's use this example to help them :) Say you have a JS source code without semicolons, then you have to keep several rules in mind, for example

   console.log('foo')
   [1,2,3].forEach(item => console.log(item))
//       ^ TypeError: Cannot read property '3' of undefined

So, in order to find such bugs (which might not be obvious), a linter can be given a rule-set, which requires a semicolon before certain token combinations. Though really, imho, please do use semicolons, it's way easier and more robust.

What kind of rules can a linter check?

A linter is a static analysis tool, so it can do any check you want on the pure text. The tool cannot execute your code in order to find problems. So, you will be able to create a ruleset from available checks, like "there must be a blank line after variable declarations", "there must be one whitespace after every comma in a list", "there must be no whitespaces at the end of a line", etc.

Can you show me an example ruleset for ESLint?

The following ESLint ruleset is taken from one of my projects. It takes different rulesets I think are useful (eslint:recommended, google, airbnb-base) and overwrites them with my own style. In addition, I tell ESLint that I want to use ES6 in a module-context on NodeJS. You can find detailed information on all the rules on the official ESLint homepage.

{
  "extends": ["eslint:recommended", "google", "airbnb-base"],
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module"
  },
  "env": {
    "node": true,
    "es6": true
  },
  "rules": {
    "eol-last": ["warn", "always"],
    "newline-before-return": "warn",
    "newline-after-var": "warn",
    "linebreak-style": ["warn", "windows"],
    "padded-blocks": ["warn", "never"],
    "max-len": ["error", {
      "code": 120
    }],
    "arrow-parens": "off",
    "no-console": "off",
    "strict": "off",
    "indent": ["error", 4],
    "no-nested-ternary": "off",
    "no-bitwise": "off",
    "comma-dangle": "warn"
  }
}

It may help to start by thinking of how types of testing complement each other:

• Static code analysis: checking the code without executing it (eg. ESLint)
• Unit tests: checking the code by executing it in isolation (eg. Jasmine)
• End to end: check the code by simulating user interactions, with full in-context code execution (eg. Selenium frameworks like webdriver.io or NightwatchJS)

There are more types of testing, obviously; but this gives some context for where ESLint fits in doing static code analysis. It processes the literal contents of your code against configured rules. The purpose is to provide code quality checks and code style enforcement. It's generally very fast and commonly set up to run whenever files are saved, giving very early error detection.

ESLint is configurable so there's no single, universal rule set (although there are popular options like AirBnB's ruleset). The possible rules are pretty extensive: eslint.org/docs/rules

Common things people check:

• Basic syntax errors
• Declaring vars at the top of scope to prevent hoisting problems
• Code complexity (encourage small, clear units of code that will be easier to unit test)
• Coding style eg. indentation, semicolons, brace style, etc
• Warn if you forget to remove a console log
• Error if there are unused variables (code cruft)

...etc.

So the end result is to lower the error rate in code; and have multiple developers producing code in a similar style (without having to talk about it in code reviews ;)).

A linter is very useful for finding semantic bugs. For example mistypes in variable names, wrong scopes, const for reassignable variables, double declarations or missing declarations, etc.

In addition ESLint is also a style linter. That means, it looks for violations of your code styling decisions (for example tab or spaces, semicolons or not, etc). This is useful for collaborative projects and working in teams.

Useful for team