Linters: don't wait to test
Tags: react, codequality, webdev, javascript
Published: 2020-08-20 19:45:46

`Linters` help you to analyse your code statically, i.e without actually even running it. This helps us:
- to catch the errors and pitfalls in the code far before doing the testing
- enforce style and coding practises so that, throughout the project, the conventions are strictly followed. 

### [ESLint](https://eslint.org/)

_ESLint_ is an open-source project originally created by _Nicholas C. Zakas_ which provides a pluggable linting utility for JavaScript. It parses your code, analyses it and runs linting rules that may trigger warnings or errors to let you know if your code is right or wrong.

#### Installation 

ESLint can be installed either globally or locally.

`npm i -g eslint` or `npm i -d eslint`

It is better to install ESLint project-wise because it will save you from running into conflicts. 

If you use VSCode, we can use the [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) plugin which is really handy. 

#### Configuration of ESLint

ESLint is highly configurable. We can do that either, using

 1. configuration comments
 2. configuration files

The second approach is easier and productive so we will explain that.

##### Configuration files

When using configuration files, it is entire project-specific. The configuration file can be a JSON, YAML or JS file. It is named `.eslintrc.*` and placed at the root of the project. Or else it can go inside the `package.json` files under the key `eslintConfig`.

To create a configuration file you can run the command

```
npx eslint --init

// or

yarn run eslint --init
```

but make sure you have `package.json` in the project root. If not you have to create one before running the init command.

##### Available options

The configuration files can take many options. A few of them are 

- `parserOptions`: tells ESLint how you want it to parse your code. The available options are:

 - `ecmaVersion`: to specify the version of ECMAScript syntax you want to use. For `es6` syntax support we can use `{ "parserOptions": { "ecmaVersion": 6 } }`, but for the latest keyword support we need to mention it using the `env`. By setting `{ "env": { "es6": true } }` the `es6` syntax support is enabled automatically.


 - `sourceType`: set to `script`(default) or `module` if your code is in ECMAScript modules.

 - `ecmaFeatures`: an object indicating which additional language features you'd like to use.

  - `globalReturn`: enable global `return`

  - `jsx`: enable `jsx` support

  - `impliedStrict`: enable global strict mode (version > ECMA5)
 
- `parser`: ESLint uses `espree` by default as the parser. We can change it by passing a `parser` option in the configuration. Even with a separate parser, `parserOptions` are to be passed. The supported parsers are:

 - esprima
 - babel-eslint
 - @typescript-eslint/parser

- `plugins`: plugins are a set of ESLint rules related to some specific subject. As an example, `eslint-plugin-react` contains many rules related to React. If needed the `eslint-plugin-` prefix can be omitted from the plugin name.

```
{
    // ...
    "plugins": [
        "jquery", // means eslint-plugin-jquery
        "@jquery/jquery", // means @jquery/eslint-plugin-jquery
        "@foobar" // means @foobar/eslint-plugin
    ]
    // ...
}
```

  _Caution_: you have to install the plugin as a `dev` 
  dependency for your rules to work properly.

- `processor`: some plugins may come with processors, which helps to extract JS code from other file types. Or it can also convert the JS code to other formats/types. [more...](https://eslint.org/docs/user-guide/configuring#specifying-processor)

- `env`: it is used to specify which environments your script is designed to run in. Each environment brings with it a certain set of predefined global variables. For example, when using testing tools like _protractor_, there are a few global keywords that are _protractor_ specific. We can use `env` to enable them. To enable an env, just add it in the object with value as true and the environment as the key.

```
{
    "env": {
        "browser": true,
        "node": true
    }
}
```


- `globals`: if there are any user-defined global variables that are being accessed inside the script, that can go inside the `globals`. 

```
{
    "globals": {
        "var1": "writable",
        "var2": "readonly"
    }
}
```

- `rules`: which rules are enabled and at what error level. Following are the error levels available:

 -`off`/`0` - turn the rule off

 -`warn`/`1` - turn the rule on as a warning (doesn't affect exit code)

 -`error`/`2` - turn the rule on as an error (exit code is 1 when triggered)

#### Ignoring files and directories

In order to ignore files from getting linted, we can do it either by creating an `ignorePatterns` field in the configuration or by creating a `.eslintignore` file in the project root.

### More read

- [For React](https://github.com/yannickcr/eslint-plugin-react)