Getting Started With ESLint

An Introduction, Popular Configs Comparison, and Resources

source: Flickr, by musicmoon@rogers.com used under CC BY / cropped, text added.

What is a Linter?

Linters have a long history in software development. Stephen C. Johnson (writings) developed Lint while debugging Yacc (Yet Another Compiler-Compiler), which was written in the C programming language at Bell Labs in 1978.

Much like the way a lint roller will go over your clothes, removing unwanted dust, hairs and other assorted undesirables (like legos), a software linter will go over and analyze your source code for possible errors, best practices and stylistic issues. Configuration options allow you to choose which bugs to identify, flag, and if desired, act on. The linter can auto-“fix” code, flag the offending code for inspection or do nothing.

The linter I’ll be using is ESLint which is an open source Javascript linting tool. It’s used by a long list of companies and organizations. You can learn more about ESLint and their philosophy on their homepage.

What are some Rule Examples?

An example of a “possible error” rule is no-debugger . It handles situations where a deadline-burdened programmer might have forgotten a debugger statement somewhere in code that is going to production. Although code with a debugger statement will open and might be functional, its not optimal. If the user opens the browser’s developer tools console, they will drop into the debugger. By choosing a setting of “error” for this rule, ESLint will flag a block of code with a debugger statement as an error:

// this code block will cause an error
function getUserName(user) {
    debugger;
    return user.name;
}

ESLint will return a list (example: sample output stylish) that contains a list of errors. Each will have a line number, column number, the severity level (e.g. error, warning) and the rule that was violated.

A “best practices” rule example is no-fallthrough , which disallows case statements that do not properly use break to prevent a “fall through” from one case statement to another.

// this code block will cause an error
switch (bird) {
    case 'robin':
        playRobinSong();
    case 'bluejay':
        playBluejaySong();
}

An interesting aspect of this rule is the optional argument it allows which is named commentPattern . Through this option, we can set a comment that tells ESLint to ignore a particular switch statement.

If we use the commentPattern “allow fallthrough” (regular expressions allowed) in the option object, then a comment with value “allow fallthrough” will be allowed to break the rule:

// optional setting for no-fallthrough rule
{ "commentPattern": "allow fallthrough" ]
// this code block will not show an error for case 1
switch(someVariable) {
    case 1:
        someFunction();
        // allow fallthrough

    case 2:
        anotherFunction();
}

Next, we have variable rules which are related to the declaration of variables. Not all of these rules are used by all companies and organizations. For example, Airbnb, Google and Standard JS each have different configurations and turn on certain rules, while leaving others turned off. One variable rule that all three organizations, as well as ESLint’s own “recommended” base configuration, turns on is no-unused-vars .

This rule minimizes the leaving behind of variables, functions and function parameters that are not actually used in the code. Let’s say we have a variable declared as jpSaxe. There are four ways a variable can be considered “used”.

1. When called as a function or constructed:

// function called
jpSaxe()
// construct a new object
new jpSaxe()

2. When read or stored as a value:

let ifTheWorld = jpSaxe;

3. When used as a parameter in a function call:

comeOverRight(jpSaxe);

4. When used inside another function:

comeOverRight(()=> {
    jpSaxe();
});

Note that there are options available for this rule. Airbnb’s default configuration has the optional args option of after-used, while the other 3 use none. This allows you to drill down and really specify the behavior that you want from ESLint.

Let’s move on to stylistic rules which handle more aesthetic issues. Here you can see the real different choices different organizations will make. Airbnb certainly chose to implement the most rules out of the 4 most popular pre-made configurations. Followed by Standard JS, then Google and finally, the least opinionated, ESLint’s own recommended implementation. In fact, ESLint’s recommended configuration has only 1 stylistic rule switched on. This is also the only rule that all 4 agree on, no-mixed-spaces-and-tabs . It’s name is self-explanatory.

And finally, there’s ESLint’s rules for ECMAScript 6. These rules can be something as syntactically minor like arrow-spacing which checks if there is proper spacing around the arrow portion of an arrow function.

// default configuration (options) object
{ "before": true, "after": true }

// sample code
() => {};   // OK
()=> {};    // not OK

// alternative configuration
{ "before": false, "after": true }

// sample code
() => {};   // not OK
()=> {};    // OK

These rules can also have a more functional purpose like improving the readability or maintainability of code. One example is prefer-const which checks if a variable declared with the let keyword is reassigned (changed) somewhere in the code. If not, it will let you know with a warning or as an error depending on how you configure the rule (0: “off”, 1:“warn”, 2:“error”).

Should I use a premade configuration or use my own?

For starters I’d definitely recommend using a premade configuration. From what I’ve read Airbnb’s configuration (npm) is the most popular. I’m not going to reinvent the wheel here and go into how to set up ESLint because there are some excellent tutorials out there.

A full list of integrations is available on the ESLint home page, and then there are these blog posts, with loads of useful information:

For VS Code:

Integrating Prettier + ESLint + Airbnb Style Guide in VSCode

Configure ESLint, Prettier, and Flow in VS Code for React Development

For Atom:

Set up ESLint in Atom

For Sublime:

Even faster code formatting using ESLint

For Vim:

Vim and eslint

For Brackets:

Installing the Brackets-ESLint NPM package | rickluna .com

Other Premade Configurations

Once you get acquainted with how to setup your ESLint to accept premade configurations you might want to look into other less popular than Airbnb like Google’s (npm)or Standard JS (website). There’s also configurations by companies such as Spotify (github), Netflix (github), Palantir (github), Naver (github), Walmart (github) and also by some individuals like Wes Bos (github) and Kent C Dodds (github).

What’s different about the 4 most popular configurations?

In my own search for a style that feels right for me I searched high and low for some kind of comparison of the ESLint rules that each configuration turned on and off. But, I couldn’t find one. 😐 The comparisons I found were mostly limited to how popular a config was, how often it was updated and generalizations about their differences.

To fix this situation I spent some time researching the differences and cataloging them in a Markdown file. They are available at github and as a gist. I hope somebody will find it worthwhile, just as I found it worthwhile to get to dig into the ESLint rules, as well as general good practices and styles for writing Javascript code. I also had a chance to look deeper into the specific options that different companies and organizations decided on, and gained a better understand of why those choices did or did not matter.