It's not necessary to initialize 'config' to undefined. Open
let config = undefined
- Read upRead up
- Exclude checks
Disallow Initializing to undefined (no-undef-init)
In JavaScript, a variable that is declared and not initialized to any value automatically gets the value of undefined
. For example:
var foo;
console.log(foo === undefined); // true
It's therefore unnecessary to initialize a variable to undefined
, such as:
var foo = undefined;
It's considered a best practice to avoid initializing variables to undefined
.
Rule Details
This rule aims to eliminate variable declarations that initialize to undefined
.
Examples of incorrect code for this rule:
/*eslint no-undef-init: "error"*/
/*eslint-env es6*/
var foo = undefined;
let bar = undefined;
Examples of correct code for this rule:
/*eslint no-undef-init: "error"*/
/*eslint-env es6*/
var foo;
let bar;
const baz = undefined;
When Not To Use It
There is one situation where initializing to undefined
behaves differently than omitting the initialization, and that's when a var
declaration occurs inside of a loop. For example:
Example of incorrect code for this rule:
for (i = 0; i < 10; i++) {
var x = undefined;
console.log(x);
x = i;
}
In this case, the var x
is hoisted out of the loop, effectively creating:
var x;
for (i = 0; i < 10; i++) {
x = undefined;
console.log(x);
x = i;
}
If you were to remove the initialization, then the behavior of the loop changes:
for (i = 0; i < 10; i++) {
var x;
console.log(x);
x = i;
}
This code is equivalent to:
var x;
for (i = 0; i < 10; i++) {
console.log(x);
x = i;
}
This produces a different outcome than defining var x = undefined
in the loop, as x
is no longer reset to undefined
each time through the loop.
If you're using such an initialization inside of a loop, then you should disable this rule.
Example of correct code for this rule, because it is disabled on a specific line:
/*eslint no-undef-init: "error"*/
for (i = 0; i < 10; i++) {
var x = undefined; // eslint-disable-line no-undef-init
console.log(x);
x = i;
}
Related Rules
- [no-undefined](no-undefined.md)
- [no-void](no-void.md) Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if (NODE_ENV == 'prod') {
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Read-only global 'process' should not be modified. Open
process = require('process')
- Read upRead up
- Exclude checks
Disallow assignment to native objects or read-only global variables (no-global-assign)
JavaScript environments contain a number of built-in global variables, such as window
in browsers and process
in Node.js. In almost all cases, you don't want to assign a value to these global variables as doing so could result in losing access to important functionality. For example, you probably don't want to do this in browser code:
window = {};
While examples such as window
are obvious, there are often hundreds of built-in global objects provided by JavaScript environments. It can be hard to know if you're assigning to a global variable or not.
Rule Details
This rule disallows modifications to read-only global variables.
ESLint has the capability to configure global variables as read-only.
- [Specifying Environments](../user-guide/configuring#specifying-environments)
- [Specifying Globals](../user-guide/configuring#specifying-globals)
Examples of incorrect code for this rule:
/*eslint no-global-assign: "error"*/
Object = null
undefined = 1
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/
window = {}
length = 1
top = 1
/*eslint no-global-assign: "error"*/
/*globals a:false*/
a = 1
Examples of correct code for this rule:
/*eslint no-global-assign: "error"*/
a = 1
var b = 1
b = 2
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/
onload = function() {}
/*eslint no-global-assign: "error"*/
/*globals a:true*/
a = 1
Options
This rule accepts an exceptions
option, which can be used to specify a list of builtins for which reassignments will be allowed:
{
"rules": {
"no-global-assign": ["error", {"exceptions": ["Object"]}]
}
}
When Not To Use It
If you are trying to override one of the native objects.
Related Rules
- [no-extend-native](no-extend-native.md)
- [no-redeclare](no-redeclare.md)
- [no-shadow](no-shadow.md) Source: http://eslint.org/docs/rules/