ESLint Rules that ESLint Rules

June 20, 2017 - -

Title inspired by The Onion

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:

  • There are way more rules (this is a good thing)
  • Easy to configure
  • Several gradations within many of the rules
  • Special rules for Node, ES6, ES7, browsers, and even React
  • It’s extensible if you want to build your own rules.
  • Excellent documentation, with plenty of examples.
  • Well designed console output
  • Well maintained
  • Easy to ignore a rule with special comment
  • Handy --fix directive to auto-fix certain rules.
  • You can override the rules on a per folder basis. This is useful if you have browser and server Javascript in the same repo.
  • Helpful Gitter channel

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:

NodeJS specific

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.

Holy wars

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.

Classic

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.

ES6 and ES7

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 don’t use with or loop labels very often, but I figure I might as well protect myself. I don’t see __iterator__ or __proto__ very often.

Good practices

I don’t like altering native libraries or using reserved words as variables. A default case is usually a good idea and return-assign is hard to read.

Clean up

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.

Misc ones I like

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.

This can probably seem overwhelming if you’re just starting, but the default recommended rules are pretty good. You’ve probably already made your Javascript better by just choosing the default rules. Also, Airbnb has a well-liked set of eslint rules as well.

Happy linting!