@nickkaramoff/eslint-config

Nikita Karamov's shareable ESLint config

Usage no npm install needed!

<script type="module">
  import nickkaramoffEslintConfig from 'https://cdn.skypack.dev/@nickkaramoff/eslint-config';
</script>

README

@nickkaramoff/eslint-config

My own shareable ESLint config.

This config enforces reasonable code style rules for style for JavaScript and TypeScript codebases. Each rule has a reason why it was added (see below).

Usage

npm install --save-dev @nickkaramoff/eslint-config

yarn add --dev @nickkaramoff/eslint-config

Then, in your ESLint config:

{
  "extends": "@nickkaramoff"
}

Rules

Every --fixable rule is always an error.

array-bracket-newline: consistent

Consistency is key to code readability. Placing a line break in arrays increases readability, but for arrays like [1, 2, 3] it is unnecessary.

camelcase

camelCase is used by most JavaScript developers. I also find it more beautiful than any other naming convention.

comma-dangle: always-multiline

Dangling commas at the end of multi-line literals (arrays, objects) can clean up your git diffs and save your from conflicts.

complexity

Reducing the cyclomatic complexity of the code improves readability and reduces error risk. This is not an enforcement though, but a recommendation.

curly: all

Not using curly braces in if, while and other statements decreases the code readability significantly. Nesting is fine, but I go for consistency in code.

dot-location: property

When the attribute dot is placed after the object, the subsequent property name on the new line seems out of place. Placing the dot at the property increases readability. Seeing, that there is neither a dot nor a semi near the object tells us to look at the next line, where the dot will explain the reason for the line break.

dot-notation

It is cleaner and more correct to access an object's properties via a dot. If you use JS objects as dictionaries, don't — there is a Map for that.

eol-last: always

Add an EOL at the end of the files to be able to concatenate them easily or output them to terminal without errors.

eqeqeq: always

=== is typesafe and will save you tons of headache when comparing things in JavaScript. null is not ignored for consistency.

for-direction

Saves you from for loops that run endlessly because of a faulty counter.

indent: tab

Using Tabs lets people choose their desired indent size while keeping the file size smaller. A double win!

  • offsetTernaryExpressions: true, because this is more correct visually
  • SwitchCase: 1, because this increases readability

linebreak-style: unix

Unix-style linebreaks are cleaner and take less space. IMO, LF should be a standard for line endings (and it de facto is). Every major editor (even notepad.exe) supports it as of 2020.

no-extra-semi

Extra semicolons are unnecessary and pollute source code.

no-implicit-coercion

Shorthands like !!foo and +bar for type casting can be clean at the first glance but they are unclear, especially for the beginners.

no-trailing-spaces

Trailing spaces are useless and only take space.

quotes: single

Single quotes are easier to type and look cleaner.

  • allowTemplateLiterals: false, because it's unnecessary when you don't use interpolation
  • avoidEscape: true, because escaping looks even less clean than double quotes

semi: always

Mandatory semicolons help people make less errors by not making them think about where JavaScript will automatically insert them.

semi-spacing

Spaces are only allowed after semicolons, just like in written languages.

wrap-iife: inside

IIFEs can be confusing, but wrapping the function separately from the call (and Function's methods) is IMO the cleanest solution.

  • functionPrototypeMethods: true, because methods of Function are, just like the function calls, separate from the function body

yoda: never

Yoda-style conditions are unnatural for the English language (which JS is based on)

Licence

ISC © 2020-2021, Nikita Karamov