DEV Community

Cover image for Linters: don't wait to test
Shihabudheen US
Shihabudheen US

Posted on • Updated on

Linters: don't wait to test

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

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 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
Enter fullscreen mode Exit fullscreen mode

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
    ]
    // ...
}
Enter fullscreen mode Exit fullscreen mode

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...

  • 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
    }
}
Enter fullscreen mode Exit fullscreen mode
  • 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"
    }
}
Enter fullscreen mode Exit fullscreen mode
  • 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

Discussion (2)

Collapse
jamesthomson profile image
James Thomson

This. Definitely this. I would argue this over automated testing, not that I'm saying you shouldn't do testing, but if you just don't have the time (or other factors) at the very least by using a linter you will improve your code quality.

Collapse
codermonkey profile image
Shihabudheen US Author

Spot on. I never write test cases. ☺️