ESLint Genius

An ESLint config for geniuses.

But you can continue to be standard if you want.

This is a combination of best practices, styles that have objective benefits, and my own (let's face it, correct) opinions. I try to provide my rationale for the more contentious decisions.

Base config

{
  "extends": "eslint:recommended",
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module"
  }
}

camelcase

"error"

Require camelCase for variables and object properties.

comma-dangle

[
  "error",
  "always-multiline"
]

Require multiline list items to have a dangling comma.

• Makes adding and reordering items a whole lot less fiddly.
• Simplifies diffs and makes them clearer. See the ESLint documentation for a good example of this.

Wrong

const things = [
	'foo',
	'bar'
];

const data = {
	foo: 'bar',
	baz: 'bat'
}

Right

const things = [
	'foo',
	'bar',
];

const data = {
	foo: 'bar',
	baz: 'bat',
};

comma-spacing

"error"

Space after commas, but not before.

comma-style

"error"

Require a comma after and on the same line as an array element, object property, or variable declaration

curly

"error"

Blocks require curly braces.

• More consistent.
• Easier and less error-prone to refactor a block later to include more lines.

Wrong

if (foo) alert(foo);

if (foo)
	alert(foo);
	alert(bar); // not inside the if block!

Right

if (foo) {
	alert(foo);
}

if (foo) {
	alert(foo);
}
alert(bar); // obviously not inside the if block.

eol-last

"error"

Require a newline at the end of files.

eqeqeq

"error"

Always require === and !==, even for literals on both sides and even when null is involved.

func-call-spacing

[
  "error",
  "never"
]

Disallow whitespace between a function call and its parens.

no-mixed-spaces-and-tabs

[
  "error",
  "smart-tabs"
]

Require tabs for indentation, but spaces for alignment. Combining them in this specific way provides the best of both.

• Tabs maintain their intended purpose of indentation, and nothing else.
• Code can always be viewed using the tab width the reader is most comfortable with.
• Lined-up code will stay lined-up no matter what.

Wrong

if (foo) {
/*ss*/alert(foo);
}

const data = {
/*tab*/foo: 'barbaz',/*tab*/ // Some descriptive text
/*tab*//*tab*//*tab*//*tab*/ // explaining this item
/*tab*/quz: 'qux',
};

Right

if (foo) {
/*tab*/alert(foo);
}

const data = {
/*tab*/foo: 'barbaz', // Some descriptive text
/*tab*//*ssssssssss*/ // explaining this item
/*tab*/quz: 'qux',
};

no-trailing-spaces

"error"

Do not allow trailing whitespace, even on blank lines.

no-var

"error"

Always require let or const as opposed to var.

prefer-const

"error"

Always prefer const as opposed to let when possible.

semi

"error"

Always require semicolons.

space-before-blocks

"error"

Require a space before the opening brace of a block.

Wrong

if (a){
	b();
}

function a(){}

try {} catch(a){}

class Foo{
	constructor(){}
}

Right

if (a) {
	b();
}

function a() {}

try {} catch(a) {}

class Foo {
	constructor() {}
}

space-before-function-paren

[
  "error",
  {
    "anonymous": "always",
    "named": "never",
    "asyncArrow": "always"
  }
]

Require a space after anonymous and arrow function parens and disallow for named function parens.

space-in-parens

[
  "error",
  "never"
]

Disallow spaces padding the insides of parens.

space-unary-ops

[
  "error",
  {
    "words": true,
    "nonwords": false,
    "overrides": {
      "!": true,
      "!!": true
    }
  }
]

Require a space after ! and !!, but not other non-word unary operators.

• It can be very easy to miss a ! (and, to a lesser extent, !!) in front of a variable when scanning code. A space instantly makes things clearer at a glance.
• Other unary operators are much easier to see.

Wrong

if (!foo) {
	badFooCount ++;
}

foo = !bar;

Right

if (! foo) {
	badFooCount++;
}

foo = ! bar;