A quick overview of ESLint Configuration Comments

Written by jlowery2663 | Published 2019/09/11
Tech Story Tags: overview-of-eslint | eslint | eslint-configuration | eslint-configuration-comments | configuration-comments | latest-tech-stories | why-use-eslint-comments | types-of-eslint-configuration

TLDR A quick overview of the types of ESLint comments, their format, and how to use them in your JavaScript. In general, it is best to use a configuration file, such as.eslintrc. Configuration files are powerful, and should be the go-to choice for enforcing ESLint rules. The ESLint documentation details both comments and configuration files, but not separately. The format differs between the two, yet the documentation presents them in conjunction with each other, making the comment formats a little hard to find in and of their own.via the TL;DR App

The ESLint documentation details both configuration comments and configuration files, but not separately. The format differs between the two, yet the documentation presents them in conjunction with each other, making the comment formats a little hard to find in and of their own. Here I will be focussing solely on the types of ESLint comments, their format, and how to use them in your JavaScript.

Why use ESLint comments?

In general, it is best to use a configuration file, such as .eslintrc. A configuration specified a file will apply to all JavaScript in that folder and its subfolders, unless overridden by another configuration file further down the folder hierarchy. Configuration files are powerful, and should be the go-to choice for enforcing ESLint rules.
“Look, that’s why there’s rules, understand? So that you think before you break ‘em.” ― Terry Pratchett
And break them you will, but not often. Where to break them is in the file comments.

What a typical comment configuration looks like

const getFinalContext = (context) => {
        /* eslint-disable-next-line no-unused-vars */
        const { calls, ...finalContext } = context;
        return finalContext;
    }
The code above does a destructuring assignment from a passed-in context parameter. The function is only interested in the rest assignment to finalContext, and “discards” the first assignment, calls. My .eslintrc rules are are normally configured to flag this as an unused variable assignment. To avoid the annoying ESLint error, I am able to disable the rule using the comment /*eslint-disable-next-line no-unused-vars*/. This only applies to the next code line, though, and the rule will remain in effect for the rest of the file.

Types of ESLint configuration comments

There are three main types:
eslint-disable/eslint-enable
The comment eslint-disable will turn off a rule from the point it is invoke until the next eslint-enable (if any). Useful for disabling flags for blocks of code. If you want to disable multiple flags, use a comma-separated list:
/* eslint-disable no-alert, no-console */
<reams of code here>
/* eslint-enable no-alert, no-console */
eslint-disable-next-line/eslint-disable-line
This disable flag only applies to the next or current line of JavaScript code. 
/* eslint-disable-next-line no-alert */
alert('foo');
alert('foo'); // eslint-disable-line no-alert
eslint-env
This is a global setting, usually appearing at the top of a JavaScript file. It sets the ‘environment’, which applies a host of rules that are tailored to the environment(s) specified. For example, eslint-env browser will turn off no-undeclared-vars warning for window and console, and eslint-env node will do the same for process. It is possible to enable multiple environments:
/* eslint-env node, mocha */

That was easy learn, hard to remember

That’s basically it! Nothing complicated, but I so seldom use these comment flags that I find myself forgetting the exact syntax. If you find yourself suffering the same memory lapses, consider bookmarking this post!

Written by jlowery2663 | I'm an early adopter kinda guy.
Published by HackerNoon on 2019/09/11