eslint-config-spreetail

This package provides an extensible ESLint configuration with a preference for helping developers avoid errors and find mistakes without being forced to adhere to opinionated, stylistic rules. It is intended for use with ES6+ projects and also supports React and JSX.

This configuration is used and maintained by Spreetail.

Installation

You will need ESLint as a dependency.

npm install eslint --save-dev

This package can be installed from npm:

npm install eslint-config-spreetail --save-dev

Usage

Once installed, add "extends": "spreetail" to your project's .eslintrc file:

{
    "extends":  "spreetail"
}

If you are using a module bundler such as webpack or rollup.js, be sure to add "sourceType": "module" to a "parserOptions" section of your project's .eslintrc file as well:

{
    "parserOptions": {
        "sourceType": "module"
    }
}

Rules

Every rule in the configuration is documented here with an explanation of its inclusion.

Philosophy

The purpose of this configuration is to aid developers rather than to coerce conformity. Therefore, it may be a bit less strict than other configurations. Great care has been taken to ensure all the rules provide a worthwhile benefit to any developer.

Warnings vs Errors

Rules which raise an error inform the developer, "This is going to break now or sometime in the future, is a security vulnerability, or will lead to poor performance." Developers should be cautious when disabling these rules.

Rules which raise a warning inform the developer, "This is probably indicative of a mistake or might not behave as one would expect." Developers can be more comfortable disabling these rules but are encouraged to understand why the rules exist and evaluate alternatives.

Rules marked here with an asterisk (*) will issue warnings rather than errors.

Possible Errors

---

no-await-in-loop

This will lead to poor performance. Use Promise.all() instead.

no-compare-neg-zero*

Comparing to -0 will pass for 0 and -0 which is confusing.

no-cond-assign

This is almost certainly a mistake.

no-console*

It clutters up the console and makes it more difficult to debug actual errors/warnings.

no-constant-condition*

This is almost certainly a mistake.

no-dupe-args*

This is almost certainly a mistake.

no-dupe-keys*

This is almost certainly a mistake.

no-duplicate-case*

This is almost certainly a mistake.

no-empty*

Empty block statements are almost certainly unintentional and may be a sign of incomplete code.

no-empty-character-class*

Empty character classes won't match anything and are probably just a sign of unfinished regex.

no-ex-assign*

Reassigning to an exception in a catch block is destructive.

no-extra-semi*

This is almost certainly a mistake.

no-func-assign*

Reassigning a function declaration (outside of the function itself) is probably a mistake and otherwise will lead to extremely confusing code.

no-invalid-regexp

This will throw an error.

no-obj-calls

This is not allowed as of ES5.

no-prototype-builtins*

It's not safe to assume the default Object.prototype methods are accessible by every object since it's possible to create objects without the default prototype.

no-sparse-arrays*

This is almost certainly a mistake.

no-template-curly-in-string*

This is almost certainly a mistake. Backticks (`) were probably intended.

no-unexpected-multiline*

This may not behave as expected due to automatic semicolon insertion.

no-unreachable*

This is almost certainly a mistake.

no-unsafe-finally*

This does not behave as expected.

no-unsafe-negation*

This is almost certainly a mistake.

use-isnan*

Comparisons directly to NaN do not behave as expected.

valid-typeof*

This is almost certainly a mistake.

Best Practices

---

array-callback-return*

This is almost certainly a mistake.

block-scoped-var*

var scoping is confusing.

consistent-return*

This is almost certainly a mistake.

curly*

Omitting curly braces can lead to code that does not behave as expected. For example:

if (foo)
    bar();
    baz();

This is actually equivalent to:

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

The multi-line option for this rule is enabled, meaning brackets may be omitted for single-line statements:

if (foo) bar();

eqeqeq*

The == and != operators use type coercion which may not behave as expected. Be explicit and use === and !== instead. The smart option for this rule is enabled.

no-caller

This is not allowed as of ES5.

no-case-declarations*

This does not behave as expected.

no-div-regex*

This is almost certainly a mistake.

no-empty-function*

This is almost certainly a mistake.

no-empty-pattern*

This is almost certainly a mistake.

no-eq-null*

This does not behave as expected.

no-eval

While there may be valid use cases for eval(), they are extremely rare, and eval() can be dangerous.

no-extend-native*

Modifying built-in prototypes can cause conflicts with other scripts and libraries. Use a function instead:

// BAD
String.prototype.getLength = function() {
    return this.length;
}
const helloLength = 'hello'.getLength();
 
// GOOD
function getStringLength(string) {
    return string.length;
}
const helloLength = getStringLength('hello');

no-extra-bind*

This is almost certainly a mistake.

no-fallthrough*

This is far more likely to be a mistake than intentional.

no-global-assign*

This is almost certainly a mistake.

no-implicit-globals*

This might be a mistake. Be explicit to avoid confusion:

// BAD
const globalVar = 'hello';
 
// GOOD
window.globalVar = 'hello'; // in the browser
// or
global.globarVar = 'hello'; // in Node

no-implied-eval

See no-eval.

no-invalid-this

This will throw an error in strict mode.

no-iterator*

This is obsolete as of ES6.

no-lone-blocks*

This is almost certainly a mistake.

no-loop-func*

This does not behave as expected.

no-new*

This is almost certainly a mistake.

no-new-func

See no-eval.

no-new-wrappers*

This does not behave as expected.

no-octal

This is deprecated as of ES5.

no-octal-escape

This is deprecated as of ES5.

no-proto

This is deprecated as of ES3.1.

no-redeclare*

This is almost certainly a mistake.

no-return-await*

This is almost certainly a mistake.

no-script-url

See no-eval.

no-self-assign*

This is almost certainly a mistake.

no-self-compare*

This is almost certainly a mistake.

no-sequences*

This is more likely to be a mistake than intentional.

no-throw-literal*

Only Error objects should be thrown, as they provide information about where they originated. Code set up to handle thrown objects typically expect that only Error objects will be thrown.

no-unmodified-loop-condition*

This is almost certainly a mistake.

no-unused-expressions*

This is almost certainly a mistake.

no-useless-concat*

This is almost certainly a mistake.

no-useless-escape*

This is almost certainly a mistake.

prefer-promise-reject-errors*

There is an expectation that Promises will only reject with an Error object. This ensures Promise rejections can be handled consistently.

radix*

Calling parseInt() with a string that starts with '0' will force evaluation as an octal, which is almost certainly a mistake. Always pass the intended radix parameter (probably 10):

// BAD
parseInt('071'); // returns 57
 
// GOOD
parseInt('071', 10); // returns 71

require-await*

This is almost certainly a mistake.

wrap-iife

Attempting to immediately execute a function declaration will cause a SyntaxError. This should be wrapped in parentheses instead.

Strict Mode

---

strict

Strict mode fixes several issues in Node scripts.

Variables

---

no-undef*

This is almost certainly a mistake (or perhaps you need to specify your project's environment or its globals in your .eslintrc file).

no-undefined*

This may not behave as expected. Use typeof myVar === 'undefined' instead.

no-unused-vars*

This is almost certainly a mistake.

no-use-before-define

This is almost certainly a mistake.

Stylistic Issues

---

array-bracket-spacing*

Leads to inconsistency in readability.

brace-style*

Leads to inconsistency in readability. We standardize the following brace style ("1tbs"):

  if (testIsTrue) {
    // Do this
  } else {
    // Do this
  }

comma-spacing*

Leads to inconsistency in readability.

func-call-spacing*

Leads to inconsistency in readability.

id-length*

Single letter variables make code difficult to read. Adds exceptions for 'i' (index) and 'e' (event).

key-spacing*

Leads to inconsistency in readability.

jsx-quotes*

Leads to inconsistency in readability. Using "" as standard.

new-cap*

Only constructors should begin with a capital letter to act as a visual differentiator between constructors and other functions or properties.

no-array-constructor*

This may not behave as expected. For example:

// BAD
const myArray = new Array(1, 2); // [1, 2]
 
const myOtherArray = new Array(3); // [undefined, undefined, undefined]

Use array literals ([]) instead:

// GOOD
const myArray = [1, 2]; // [1, 2]
 
const myOtherArray = [3]; // [3]

no-multi-assign

This can lead to the accidental decleration of global variables.

no-nested-ternary

This is difficult to read.

quotes*

Leads to inconsistency in readability. Using "" due to this.

quote-props*

Leads to inconsistency in readability. Using "as-needed" option.

semi

Automatic semicolon insertion* may not behave as expected. Use semicolons instead of relying on ASI.

space-before-blocks*

Leads to inconsistency in readability.

space-in-parens*

Leads to inconsistency in readability.

ECMAScript 6

---

arrow-spacing*

Leads to inconsistency in readability

constructor-super

This will raise a runtime error.

no-class-assign*

This is almost certainly a mistake.

no-const-assign

This will raise a runtime error.

no-dupe-class-members*

This is almost certainly a mistake.

no-duplicate-imports*

This is almost certainly a mistake.

no-new-symbol

This will throw a TypeError.

no-this-before-super

This raises a reference error.

no-useless-computed-key*

This is almost certainly a mistake.

no-var*

var behavior can be confusing and unexpected. Use const or let instead. See this article for more information.

object-shorthand*

This is a solid time saver and avoids repetition.

prefer-const*

Best practice to use const if a variable is not re-assigned.

prefer-rest-params*

The arguments object does not behave as expected. It is "array-like" rather than a real array. Instead of using arguments, use rest parameters.

prefer-template*

Leads to inconsistency in readability.

// BAD
function () {
    const args = Array.prototype.sice.call(arguments);
    // do something with the args array
};
 
// GOOD
function(...args) {
    // do something with the args array
}

require-yield*

This is almost certainly a mistake.

symbol-description

This will throw a TypeError.

React

---

react/button-has-type*

This may not behave as expected.

react/default-props-match-prop-types*

This is almost certainly a mistake.

react/no-danger

This is a security vulnerability.

react/no-danger-with-children

Component children and dangerouslySetInnerHTML conflict with one another.

react/no-deprecated

Deprecated methods will eventually be removed and should not be used.

react/no-direct-mutation-state*

This is almost certainly a mistake.

react/no-find-dom-node

This will eventually be deprecated, see react/no-deprecated.

react/no-is-mounted

This will eventually be deprecated, see react/no-deprecated.

react/no-redundant-should-component-update*

This is almost certainly a mistake.

react/no-render-return-value

This is legacy functionality.

react/no-typos*

This is almost certainly a mistake.

react/no-this-in-sfc*

This is almost certainly a mistake.

react/no-string-refs

This is legacy functionality.

react/no-unescaped-entities*

This is almost certainly a mistake.

react/no-unknown-property*

This is almost certainly a mistake.

react/no-unused-prop-types*

This is almost certainly a mistake.

react/no-unused-state*

This is almost certainly a mistake.

react/prefer-es6-class*

This may be removed in the far distant future.

react/prefer-stateless-function*

This will lead to worse performance. The ignorePureComponent option is enabled.

react/prop-types*

This is almost certainly a mistake.

react/react-in-jsx-scope

React is required in the scope of any JSX.

react/require-render-return* This is almost certainly a mistake.

react/style-prop-object

This will cause an error.

react/void-dom-elements-no-children*

This is almost certainly a mistake.

JSX

---

react/jsx-filename-extension

This may be required for build configurations.

react/jsx-key

This is more or less required by React for performance reasons.

react/jsx-no-comment-textnodes*

This is almost certainly a mistake.

react/jsx-no-duplicate-props*

This is almost certainly a mistake.

react/jsx-no-target-blank

This is a security vulnerability.

react/jsx-no-undef

This will throw a ReferenceError. The allowGlobals option is enabled.

react/jsx-pascal-case*

This is largely a universal standard.

react/jsx-uses-react

This prevents other linting errors.

react/jsx-uses-vars

This prevents other linting errors.

License

Licensed under the MIT License.