paint-brush
ESLint configuration commentsby@jlowery2663
2,139 reads
2,139 reads

ESLint configuration comments

by jeffloweryJanuary 13th, 2019
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

The <a href="https://eslint.org/docs/user-guide/configuring" target="_blank">ESLint documentation</a> 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.

Company Mentioned

Mention Thumbnail
featured image - ESLint configuration comments
jefflowery HackerNoon profile picture

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 above code 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-enableThe 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-lineThis 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-envThis 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!