@maxkagamine/eslint-config v1.2.2

@maxkagamine/eslint-config

Personal eslint config, available for anyone to use. Supports both JS & TypeScript.

• 2 spaces for indentation, including switch cases.
• Single quotes for strings, including JSX, except to avoid escaping.
• Semicolons are yes.
• == is preferred. Better to be aware of what types you're dealing with ahead of time; === exists for those cases where you need to also check for same type. Consider TypeScript for improved type safety.
• Spacing around keywords, curlies, etc. as usual; no space after function names.
• Catches unused variables, other useless code, and various errors.
• Only errors are errors. Things that are not errors are not errors.
• Deliberately tries not to be too over-aggressive, with the premise that one should not have to fight their linter.

Also includes a base config that aims to provide a more sensible and lightweight alternative to eslint:recommended, which you can use as a base for your own code style rules without having to deal with the boilerplate.

For JavaScript, uses the Babel parser to support the latest and greatest.

Rules

To keep the config files easily readable, rules are grouped as follows (and sorted matching the eslint docs):

Base config

• Errors — Unlike eslint:recommended, error is used strictly for invalid syntax, definite runtime errors, and incorrect usage; anything that is not actually an error is set to warn, although one may wish to set e.g. no-debugger as an error at the project level for the sake of stopping a build.

  Exception: missing semis are treated as syntax errors and thus marked as error, even though they technically are not.

• Useless code — Generally any code that serves no purpose and can safely be removed. Includes unused variables and unreachable code.

• Misc — Other rules generally good to have on all projects but bordering between objective and subjective:

  • debugger statements are flagged to remember to remove them (no-debugger).
  • No irregular whitespace characters like non-breaking and fullwidth spaces (no-irregular-whitespace).
    • Except in strings & comments, to support languages like Japanese.
  • no-var assuming ES6; disable to fall back to block-scoped-var for ES5 projects.
  • Cases should be wrapped in a block if they contain variable declarations, as they are not block-scoped otherwise; necessary particularly for complex switch statements (no-case-declarations).
  • Always specify a radix to parseInt() to avoid accidental hex parsing (radix).
  • No trailing spaces, and files should end in a newline (no-trailing-spaces, eol-last).
    • Your editor can most likely handle this automatically; see "Usage" below for VS Code.
  • Merge duplicate imports, e.g. different named imports from the same file (no-duplicate-imports).
  • For JavaScript, includes valid-jsdoc, configured to be as permissive as possible (does not force their use), in order to help ensure that jsdoc params match their functions. Note that this may cause warnings on comments that look like jsdocs but is often worthwhile, as editors (VS Code) can use these to provide better typing even without TS.
    • For TypeScript, see tsdoc.

• Style preference defaults — The standard semi, indent, and quotes which are typically configured for every project anyway, included for convenience and set as described at the top. Uses babel/semi to cover class properties. Override as necessary if only using the base config.

Full config

• Style preferences — Code style rules outside of spacing. Includes some which could be considered "useless code" but are kept out of the base config as opinions differ.

  • No yoda conditions.
  • Use parenthesis for constructors, e.g. new Foo() instead of new Foo (new-parens).
  • Use object-shorthand when possible to avoid repetition, e.g. { foo } instead of { foo: foo }.
  • Omit unnecessary parenthesis and returns in arrow functions, e.g. x => x.foo instead of (x) => { return x.foo; } (arrow-body-style, arrow-parens).
  • Self-executing functions are wrapped with the calling () on the outside (wrap-iife).
  • Interfaces use semicolons (typescript/member-delimiter-style).
  • Braceless if statements are allowed if desired. This can be nice for brevity, and the indent rule catches mistakes.

• Spacing & alignment — General code formatting, broken out from the above to keep the "Style preferences" section simpler. Most are fairly typical, like spacing around curlies, while some are more subjective, like no trailing commas. Tries not to be too heavy-handed. Going down the line:

  • Dots at the beginning of lines (dot-location); commas (comma-style) and semicolons (semi-style) at the end.
  • Spacing around curlies (block-spacing, object-curly-spacing, space-before-blocks), keywords (keyword-spacing, space-unary-ops), operators (space-infix-ops), and arrows (arrow-spacing).
  • Space after commas (comma-spacing) and colons (key-spacing, switch-colon-spacing, typescript/type-annotation-spacing).
  • Same-line braces (brace-style).
  • No trailing commas (comma-dangle).
  • No spacing in property brackets (computed-property-spacing), template curlies (template-curly-spacing), or JSX curlies (react/jsx-curly-spacing, if available).
  • No space before function call parenthesis (func-call-spacing), after function names, or before the parenthesis in anonymous functions (space-before-function-paren).
  • No space after dots (no-whitespace-before-property), template tags (template-tag-spacing), or rests/spreads (rest-spread-spacing).
  • No spacing around non-keyword unary operators (space-unary-ops).
  • Generator & yield stars attached to the keyword, MDN-style (generator-star-spacing, yield-star-spacing).
  • No space around JSX attribute equals (react/jsx-equals-spacing, if available).
  • Space before JSX element self-closing slash (react/jsx-tag-spacing, if available).
  • Spacing inside array brackets preferred but not enforced, as it sometimes looks better having them compact.

Usage

Copy pasta:

npm install -D @maxkagamine/eslint-config babel-eslint eslint-plugin-babel eslint

{
  "extends": "@maxkagamine"
}

For the base config, use @maxkagamine/eslint-config/base.

VS Code can fix trailing whitespace and newlines at EOF automatically, in which case the corresponding warnings from the eslint extension can be squelched to reduce noise:

"eslint.options": { 
  "rules": {
    // Editor takes care of these
    "no-trailing-spaces": "off",
    "eol-last": "off"
  }
},
"files.insertFinalNewline": true,
"files.trimTrailingWhitespace": true,
"[markdown]": {
  "files.trimTrailingWhitespace": false
},

TypeScript

npm install -D @maxkagamine/eslint-config typescript-eslint-parser eslint-plugin-typescript eslint-plugin-babel eslint

{
  "extends": "@maxkagamine/eslint-config/typescript"
}

The babel plugin is used here, too, but babel itself is not required.

For the base config, use @maxkagamine/eslint-config/typescript/base.

To lint TypeScript files, run eslint with --ext .js,.ts,.tsx. For VS Code, add the following to your workspace settings:

"eslint.validate": [
  "javascript",
  "javascriptreact",
  "typescript",
  "typescriptreact"
]

React

npm install -D eslint-plugin-react

"extends": [ "@maxkagamine", "plugin:react/recommended" ]

The config will make use of additional React plugin rules automatically if installed.