ESLint Rules that ESLint Rules

I recently embarked on a new Node.JS project, and after having used JSHint for several previous projects, I wanted to read up on ESLint and give it a shot. I’m a big fan of static analysis tools particularly for untyped languages like Javascript. They catch a ton of bugs by enforcing best practices and looking for known pitfalls. They also help keep your code clean and consistent. I strongly recommend using a linter, and it’s much easier to start using one earlier than later in a project. Anyways, it didn’t take long to realize that ESLint is wildly superior to it’s predecessors for several reasons:

I know I’m a little behind the times here, but I’m fully on the ESLint train. Here’s my whole set of rules which extend the ESLint recommended rules. Since I’m early in my project, I have a feeling some of these will change if I get too annoyed by them. I have them all set to error. In my experience, people tend to ignore compiler/linter warnings, so I prefer errors to enforce build failures. My choices were based on:

Will these catch likely errors and ensure good decisions by future me and potential future collaborators?

Is this a rule I would want enforced >90% of the time?

I don’t want to talk about every single rule, so I’ll arbitrarily bunch them up:

Callback returns have gotten me a few times. I use a callback in the middle of a function, but since I didn’t return the rest of the function gets executed which is rarely desirable. I also love the restricted modules rule. Occasionally, I use wrappers around some libraries and this helps enforce the usage of the wrapper instead of the library. In Node, it’s preferred to avoid synchronous io, so you should have a good reason for using it.

I don’t want to get into a space vs tab or single vs double quote debate. I like these rules because they can enforce the style (or lack there of) of your choosing, and you don’t have to worry about all sorts of weird git commit diffs. I happen to prefer enforcing curly braces for if-statements, and I don’t care much about single vs double quotes, but that’s just me. I don’t know if max-len is a holy war exactly, but I have it set so that I don’t have to horizontally scroll on my current screens configuration.

I remember these from JSLint and JSHint. I prefer semicolons and I think eqeqeq is still a good practice. The radix rule might be a little dated because as of ES5, you no longer have to worry about pesky octals, but hexadecimal numbers can cause unwanted results. And, avoiding eval remains wise.

I’m using ES6/ES7 full time (for Node use anyways). I don’t use var, I’m using await/async for all my asynchronous logic, and the spread operator is pretty useful. The prefer-template rule tripms me up a lot. For short strings, adding a couple strings together is a little easier for me to read than templates, but maybe I’m just used to the old ways of doing things.

Things that don’t happen often, but there’s no harm in protecting against them anyways.

I like rules that catch unused code (which is sometimes an error). No-magic-numbers bites me a lot, but it’s definitely nicer to have named constants. For browsers I allow error and warn for for no-console.

I also like to remember to "use strict"; and to throw only Error (or subclasses). The array-callback-return rule is a handy one. The last one, no-unsafe-regex, is an eslint plugin to prevent unsafe, exponential time regexes.