@bmearns/eslint-config

eslint-config-mearns

My eslint styling rules for NodeJS projects.

Use

> npm install --save-dev git+https://github.com/mearns/eslint-config-mearns.git
> npm install --save-dev eslint@7

Set your .eslintrc.json as follows:

{
    "extends": ["@bmearns/eslint-config"]
}

Optionally, but recommended:

> npm install --save-dev prettier@1 pretty-quick@2 husky

And merge the following into your package.json:

{
    "scripts": {
        "check:eslint": "eslint --max-warnings 0 --format codeframe .",
        "pretty": "pretty-quick --staged"
    },
    "husky": {
        "hooks": {
            "pre-commit": "npm run pretty -s"
        }
    }
}

Overview

Parses ECMA Version 12, rules based on "JavaScript Standard Style" and Prettier (v1), but with semicolons.

The rules start with "standard" but we put semicolons back in because some people are really adverse to relying on ASI. Our rules require the use of semicolons to terminate statements, require a space after a semicolon and prohibit a space before a semicolon, and prohibit the use of extra-semicolons (semicolons that create empty statements).

We also use the "prettier/recommended" configuration and specifically set all prettier rules to "error" level (some default to "warning").

Finally, we add a "no-warning-comments" rule which will fail if any comment contains strings "FIXME", "TODO", or "XXX" (case-insensitive in all cases). This isn't to imply you shouldn't use comments like this, these rules allow you to use them to flag things that you need to fix before you merge or publish. However, these rules do imply that there shouldn't be any long-lived use of these comments: use an issue tracker for that.

Variations

If you're using jest, you might want to extends "@bmearns/eslint-config/jest"; this will set appropriate overrides for files under the test/ directory.

If you're writing in typescript, you probably want to use "@bmearns/eslint-config/typescript", which will set appropriate overrides for typescript files (based on ".ts" extension). Note that you'll want to have this after the jest variant if you're using both.

Prettier

Note that we stick with prettier version 1. Version 2 introduced a lot of stuff that we don't care for, like trailing commas at the end of array and object literals. It also seems to clash with the "prettier/recommended" rules so you end up with your auto-formatter changing things and then your linter telling you to change it back in a never ending battle.