@voxpelli/eslint-config

My personal ESLint config which extends standard / semistandard with a couple of extra checks that I find helpful in my projects.

Includes the semistandard rules directly rather than relying on eslint-config-semistandard, as that package isn't always trailing the main eslint-config-standard package.

This package follows semantic versioning. Tightening of any checks is a breaking change, therefore that will only happen in major releases. Minor and patch releases will only include relaxation of rules or fixing of minor obvious oversights.

Can I use this in my own project?

Absolutely, go ahead! I maintain this project as if multiple people are using it. Be sure to give me feedback and if you like it, give me a ping and say so, would make my day 😄

Usage

Install

Be sure to install the correct versions of peer dependencies that this module requires, else you will likely get an incorrect rule setup.

To easily install all correct peer dependencies, you can use install-peerdeps:

install-peerdeps --dev @voxpelli/eslint-config

Configure

Add an .eslintrc, or other ESLint configuration, that extends this config:

{
  "extends": "@voxpelli",
  "root": true
}

Configure, ESM

Instead of simply extending @voxpelli you can extend @voxpelli/eslint-config/esm and get a version of the rules that enforces ESM best practices as well.

How does this differ from pure standard?

• :stop_sign: = changed to error level
• :warning: = changed to warn level
• :mute: = deactivated
• :wrench: = changed config
• :grimacing: = will not pass vanilla standard linting

:wrench: Changed standard rules

• :wrench::warning::grimacing: comma-dangle – changed – prefer dangling commas in everything but functions + is it set to warn rather than error as I gradually move to this setup
• :mute: dot-notation – deactivated – clashes with the noPropertyAccessFromIndexSignature check in TypeScript, which I use
• :wrench::grimacing: no-multi-spaces – changed – sets ignoreEOLComments to true, can be useful for more readable comments across multiple lines and I see no real downsides to it (Incompatible with standard)
• :wrench: no-unused-vars – changed – sets "args": "all", "argsIgnorePattern": "^_", because I personally don't feel limited by Express error handlers + wants to stay in sync with TypeScript noUnusedParameters
• :wrench::grimacing: semi and no-extra-semi – changed – adopts the semicolons setup from semistandard (Incompatible with plain standard, compatible with semistandard)
• :wrench::warning: n/no-deprecated-api – changed – changed to warn instead of error as often it's not an urgent thing to fix

:heavy_plus_sign: Added ESLint core rules

• :warning: func-style – disallows function declarations, good to be consistent with how functions are declared
• :warning: no-console – warns on existence of console.log and similar, as they are mostly used for debugging and should not be committed
• :stop_sign: no-constant-binary-expression – errors when binary expressions are detected to constantly evaluate a specific way
• :stop_sign: no-nonoctal-decimal-escape – there's no reason not to ban it
• :stop_sign: no-unsafe-optional-chaining – enforces one to be careful with .? and not use it in ways that can inadvertently cause errors or NaN results
• :warning: no-warning-comments – warns of the existence of FIXME comments, as they should always be fixed before pushing
• :stop_sign: object-shorthand – requires the use of object shorthands for properties, more tidy
• :stop_sign: quote-props – requires properties to be quoted when needed but otherwise disallows it

:package: Added ESLint rule package

• plugin:n/recommended
• plugin:security/recommended
• plugin:mocha/recommended
• plugin:unicorn/recommended
• plugin:promise/recommended
• plugin:jsdoc/recommended

:wrench: Overrides of added ESLint rule packages

• :mute: jsdoc/check-types – deactivated – to improve use with types in js.

• :mute: jsdoc/no-undefined-types – deactivated – to improve use with types in js.

• :mute: jsdoc/require-jsdoc – deactivated – to improve use with types in js.

• :mute: jsdoc/require-param-description – deactivated – to improve use with types in js.

• :mute: jsdoc/require-property-description – deactivated – to improve use with types in js.

• :mute: jsdoc/require-returns-description – deactivated – to improve use with types in js.

• :mute: jsdoc/require-yields – deactivated – to improve use with types in js.

• :wrench: jsdoc/tag-lines – changed – to enforce an empty line between description and tags, but disallow them elsewhere.

• :mute: jsdoc/valid-types – deactivated – to improve use with types in js.

• :mute: mocha/no-mocha-arrows – deactivated – while Mocha discourages arrow functions I find it more readable to use them + I find it safe when type checking ones test files as then the type checking will notify one when one tries to do a this.setTimeout() or similar in an arrow function where there is no such local context

• :mute: n/no-process-exit – deactivated – added by plugin:n/recommended, but deactivated in favor of unicorn/no-process-exit

• :mute: security/detect-object-injection – deactivated – causes too many false errors

• :mute: security/detect-unsafe-regex – deactivated – at least early on wasn't very stable

• :wrench: unicorn/catch-error-name – changed – I prefer err over error as I find errorto be a far too similar name to the built in Error class

• :mute: unicorn/explicit-length-check – deactivated – I don't see an issue with if (string.length) instead of if (string.length !== 0)

• :warning: unicorn/unicorn/no-await-expression-member – changed – eg. useful in chai tests

• :warning: unicorn/unicorn/no-negated-condition – deactivated – turned off, there are valid cases for this, so it simply gets noisy

• :mute: unicorn/numeric-separators-style – deactivated – currently not enough good support for this in engines

• :warning: unicorn/prefer-add-event-listener – changed – set to warn instead of error

• :warning: unicorn/prefer-event-target – changed – set to warn instead of error

• :mute: unicorn/prefer-module – deactivated – only useful when you know you're targetting ESM

• :warning: unicorn/prefer-spread – changed – set to warn instead of error

• :warning: unicorn/prefer-string-replace-all – changed – set to warn instead of error

• :mute: unicorn/prevent-abbreviations – deactivated – same as unicorn/catch-error-name, I prefer an abbreviated err over a non-abbreviated errorbecause the latter is too similar to Error for my taste

• :wrench: unicorn/switch-case-braces – changed – I prefer to avoid braces in case statements rather than enforcing them

:heavy_plus_sign: Additional standalone ESLint rules

• :warning: es-x/no-exponential-operators – disallows the use of the ** operator, as that's in most cases a mistake and one really meant to write *

• :warning: import/no-deprecated – disallows the use of explicitly deprecated code (code marked with @deprecated)

• :stop_sign: import/no-order – enforces a specific ordering of imports

• :warning: n/prefer-global/console

• :warning: n/prefer-promises/fs

• :warning: n/no-process-env

• :stop_sign: n/no-sync

• :stop_sign: promise/prefer-await-to-then

• :stop_sign: sort-destructure-keys/sort-destructure-keys

Extended ESM config

By extending @voxpelli/eslint-config/esm instead of @voxpelli you will get these differences:

:wrench: Overrides of rules

• :warning: func-style – enforces function declarations whenever an arrow function isn't used. Better to do export function foo () { than export const foo = function () {
• :stop_sign: unicorn/prefer-module – changed – restored to its plugin:unicorn/recommended value of error

Alternatives

• eslint-config-rainbow by @bcomnes
• semistandard
• standard

See also

• voxpelli/ghatemplates – the templates I use with ghat to update GitHub Actions in my projects
• voxpelli/renovate-config-voxpelli – the shareable Renovate setup I use in my projects
• voxpelli/tsconfig – the shareable tsconfig.json setup I use in my projects