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.
You will need ESLint as a dependency.
npm install eslint --save-devThis package can be installed from npm:
npm install eslint-config-spreetail --save-devOnce 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"
}
}Every rule in the configuration is documented here with an explanation of its inclusion.
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.
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.
This will lead to poor performance. Use Promise.all() instead.
Comparing to -0 will pass for 0 and -0 which is confusing.
This is almost certainly a mistake.
It clutters up the console and makes it more difficult to debug actual errors/warnings.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is almost certainly a mistake.
Empty block statements are almost certainly unintentional and may be a sign of incomplete code.
Empty character classes won't match anything and are probably just a sign of unfinished regex.
Reassigning to an exception in a catch block is destructive.
This is almost certainly a mistake.
Reassigning a function declaration (outside of the function itself) is probably a mistake and otherwise will lead to extremely confusing code.
This will throw an error.
This is not allowed as of ES5.
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.
This is almost certainly a mistake.
This is almost certainly a mistake. Backticks (`) were probably intended.
This may not behave as expected due to automatic semicolon insertion.
This is almost certainly a mistake.
This does not behave as expected.
This is almost certainly a mistake.
Comparisons directly to NaN do not behave as expected.
This is almost certainly a mistake.
This is almost certainly a mistake.
var scoping is confusing.
This is almost certainly a mistake.
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();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.
This is not allowed as of ES5.
This does not behave as expected.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is almost certainly a mistake.
This does not behave as expected.
While there may be valid use cases for eval(), they are extremely rare, and eval() can be dangerous.
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');This is almost certainly a mistake.
This is far more likely to be a mistake than intentional.
This is almost certainly a mistake.
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 NodeSee no-eval.
This will throw an error in strict mode.
This is obsolete as of ES6.
This is almost certainly a mistake.
This does not behave as expected.
This is almost certainly a mistake.
See no-eval.
This does not behave as expected.
This is deprecated as of ES5.
This is deprecated as of ES5.
This is deprecated as of ES3.1.
This is almost certainly a mistake.
This is almost certainly a mistake.
See no-eval.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is more likely to be a mistake than intentional.
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.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is almost certainly a mistake.
There is an expectation that Promises will only reject with an Error object.
This ensures Promise rejections can be handled consistently.
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 71This is almost certainly a mistake.
Attempting to immediately execute a function declaration will cause a SyntaxError.
This should be wrapped in parentheses instead.
Strict mode fixes several issues in Node scripts.
This is almost certainly a mistake (or perhaps you need to specify your project's environment or its globals in your .eslintrc file).
This may not behave as expected. Use typeof myVar === 'undefined' instead.
This is almost certainly a mistake.
This is almost certainly a mistake.
Leads to inconsistency in readability.
Leads to inconsistency in readability. We standardize the following brace style ("1tbs"):
if (testIsTrue) {
// Do this
} else {
// Do this
}Leads to inconsistency in readability.
Leads to inconsistency in readability.
Single letter variables make code difficult to read. Adds exceptions for 'i' (index) and 'e' (event).
Leads to inconsistency in readability.
Leads to inconsistency in readability. Using "" as standard.
Only constructors should begin with a capital letter to act as a visual differentiator between constructors and other functions or properties.
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]This can lead to the accidental decleration of global variables.
This is difficult to read.
Leads to inconsistency in readability. Using "" due to this.
Leads to inconsistency in readability. Using "as-needed" option.
Automatic semicolon insertion* may not behave as expected. Use semicolons instead of relying on ASI.
Leads to inconsistency in readability.
Leads to inconsistency in readability.
Leads to inconsistency in readability
This will raise a runtime error.
This is almost certainly a mistake.
This will raise a runtime error.
This is almost certainly a mistake.
This is almost certainly a mistake.
This will throw a TypeError.
This raises a reference error.
This is almost certainly a mistake.
var behavior can be confusing and unexpected.
Use const or let instead.
See this article for more information.
This is a solid time saver and avoids repetition.
Best practice to use const if a variable is not re-assigned.
The arguments object does not behave as expected.
It is "array-like" rather than a real array.
Instead of using arguments, use rest parameters.
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
}This is almost certainly a mistake.
This will throw a TypeError.
This may not behave as expected.
This is almost certainly a mistake.
This is a security vulnerability.
Component children and dangerouslySetInnerHTML conflict with one another.
Deprecated methods will eventually be removed and should not be used.
This is almost certainly a mistake.
This will eventually be deprecated, see react/no-deprecated.
This will eventually be deprecated, see react/no-deprecated.
This is almost certainly a mistake.
This is legacy functionality.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is legacy functionality.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is almost certainly a mistake.
This may be removed in the far distant future.
This will lead to worse performance. The ignorePureComponent option is enabled.
This is almost certainly a mistake.
React is required in the scope of any JSX.
react/require-render-return* This is almost certainly a mistake.
This will cause an error.
This is almost certainly a mistake.
This may be required for build configurations.
This is more or less required by React for performance reasons.
This is almost certainly a mistake.
This is almost certainly a mistake.
This is a security vulnerability.
This will throw a ReferenceError.
The allowGlobals option is enabled.
This is largely a universal standard.
This prevents other linting errors.
This prevents other linting errors.
Licensed under the MIT License.