eslint-config-calebmer

An opinionated eslint config with attitude 😘

Based on the standard coding style except more strict and more opinions.

Features

• Enhanced promise rules.
• ES module static linting configuration which checks for existing imports/exports.
• JSDoc specific rules for the best documentation in the land!
• Test environment (via calebmer/tests) with Mocha specific rules.
• Markdown code block linting. Just remember to run eslint with an extension argument: eslint --ext md ….

Bikeshedding

If you don’t like a rule, we can do some bikeshedding, just open an issue. If we can’t quickly come to a resolution, my subjective preference wins out.

Warrants for some rules are below.

Warrants

Some of the decisions made in this config may be controversial, or I may forget why I made them. Therefore here are my warrants for some of the more controversial decisions made in this config.

Table of contents:

• Semicolons
• Brace Style
• Comma Dangle
• No Namespace Imports

Semicolons

Semicolons are disabled. I don’t want to write any more characters than I have to. Deal with it 😎

Brace Style

The brace style is configured to Stroustrup. This forces braces from if/else statements to act like this:

// Yep 👍

if (foo) {
  bar()
}
else {
  baz()
}

…instead of the more common style one true brace style which looks like this:

// Nope 😫

if (foo) {
  bar()
} else {
  baz()
}

There are three reasons for choosing Stroustrup.

1. Documentation

When doing algorithm documentation for if/else statements it is very hard to decide where to write documentation with the “one true brace style.” Do you write documentation at the start of the if/else block? Do you write documentation inside the if/else blocks? To demonstrate:

// Does documentation go here?
if (foo) {
  // Or here?
  bar()
// But definetly not here…
} else {
  // If it goes here it may be confused for documenting `baz` instead of the block as a whole.
  baz()
}

But with Stroustrup documenting if/else blocks is easy.

// Document the if here. 👍
if (foo) {
  bar()
}
// Document the else here. 🎉
else {
  baz()
}

2. Consistency

You would never write this:

function hello () {
  // Stuff…
} function world () {
  // Other stuff…
}

Or if/if statements like this:

if (foo) {
  // Stuff…
} if (bar) {
  // Other stuff… 😯
} try {
  // More stuff… 😵
} catch (error) {
  // Yeah, no stuff here 😉
}

So why write your if/else blocks or try/catch blocks that way? One argument may be that if/else and try/catch blocks are one piece of application logic, to counter that take a look at promises:

asyncWork()
.then(foo => {
  // More async work… 🤔
})
.then(bar => {
  // Finish async work…
})
.catch(noop)

This configuration prefers the above code over:

// Yikes! 😟
asyncWork()
.then(foo => {
  // More async work…
}).then(bar => {
  // Finish async work…
}).catch(noop)

As this choice in method chaining ends up acting very similar to if/else blocks (in a logic sense), we pick Stroustrup for consistency.

3. Spacing

The so called “one true brace style” can get very compact and become almost unreadable with lots of else ifs.

if (foo) {
  bar()
} else if (baz) {
  bux()
} else {
  quz()
}

Comma Dangle

Inspired by “Why you should enforce Dangling Commas for Multiline Statements” this configuration enforces dangling commas for multiline statements. So the following code is invalid:

// Yeah, no…

const array = [
  'foo',
  'bar',
  'buz'
]

But the following code is valid:

// Yay! 🎉

const array = [
  'foo',
  'bar',
  'buz',
]

Note that the only difference between the two examples is a single comma. For the main argument, read the article linked to earlier, but the gist of the article is that enforcing dangling commas for multiline statements is preferable because you only have to change one line instead of two when adding an item to a multiline object.

This has two impacts:

1. Better git diffs.
2. Easier to edit.

Therefore this rule is enforced in this configuration.

No Namespace Imports

If you try to import values from an ES module like so:

import * as foo from './foo'

You will get an error.

Why is this? Well because doing this can lead to importing everything from a module. This is an anti-pattern when you are code splitting your modules trying to make the smallest build possible. Instead of depending on a namespace import, instead use a default export object like so:

export default {
  foo: 1,
  bar: 2,
  baz: 3,
}

This way you are more explicit about your intent for the exports.

Ultimately, named exports should be used when you want the user to be selective about their module imports.