Automate best practice in 5 minutes with ESLint

What is ESLint?

Good question, glad you asked. Let me act like a politician, and instead of answer it, redirect by asking you a question. Do you find sorting formatting in accordance with a style guide a hassle? Do you find yourself frustrated with overuse of logging statements? Does inconsistent bracketing raise your blood pressure?

If you answered yes to the above, then first and foremost you probably need a holiday. But once you’re back from your holiday, you should start using a linter. A linter performs “linting” - a type of static analysis that finds patterns or code that doesn’t fit a set of style guidelines. And what is static analysis? Static analysis is the analysis of software without actually executing the code - aka it just looks at how the code is written, it doesn’t check he validity of any outputs. This is actually especially important for JavaScript (I’ll call it “JS” from now on), because JS is a dynamic and loosely typed language. This means it is especially prone to developer error (note, despite being true, this excuse is unlikely to go down well with your boss).

So finally, what is ESLint? ESLint is a plugin that scans your JavaScript code, finds, and [often] automatically fixes the problems it finds. ESLint is Node.js, and Node.js exclusively, and it can handle JSX and TypeScript when a plugin or transpiler is used.

How to set up ESLint

ESLint is easy to install using npm or yarn. To use npm, from inside a project directory, run:

npm install eslint —save-dev

Following which you should set up a config file, which is as easy as

npx eslint —init

Running this will create a config file, normally named .eslintrc.js. Inside this you will see something like the following:

"rules": {
 "semi": ["error", "always"],
 "quotes": ["error", "double"],
 "no-console": "warn"
 }

This is how rules are set up in ESLint. The names (in this example, “semi”, “quotes” and “no-console” ) are the names of rules to be applied when ESLint is run. The second value (in this example, “error”, “error” and “warn”) are the levels of warning ESLint will give if it encountered code that violates the rule. Warn will just print a warning to the console, while error will return a non-zero exit code, which can be used by other programs to - for example - stop deployment to a code pipeline, or stop committing, or something else. Once you have set up ESLint, it can be run from the command line using

npx run eslint 

Common options for ESLint

There are a large range of pre-baked rules for ESLint, see the rules (https://eslint.org/docs/rules/). Even better than that, many of these rules (specifically, the rules that have a tick symbol beside them here https://eslint.org/docs/rules/) come enabled by default with ESLint. Useful examples of these pre-enabled rules are not allowing duplicate arguments in function definitions, disallowing extra semi colons, enforcing the use of isNaN() when checking for NaNs, and many more. Reading through the rules https://eslint.org/docs/rules/ is highly recommended, both to see what is being enforced by default, and also to check whether you recognise any in your own bad habits…

And that’s all folks!

That should be quite enough to get started with ESLint. In addition, you may want to look into prettier and husky, as additional ways to automate the annoying stuff.