Showing 1,086 of 1,086 total issues
Don't use process.exit(); throw an error instead. Open
process.exit(code);
- Read upRead up
- Exclude checks
Disallow process.exit() (no-process-exit)
The process.exit()
method in Node.js is used to immediately stop the Node.js process and exit. This is a dangerous operation because it can occur in any method at any point in time, potentially stopping a Node.js application completely when an error occurs. For example:
if (somethingBadHappened) {
console.error("Something bad happened!");
process.exit(1);
}
This code could appear in any module and will stop the entire application when somethingBadHappened
is truthy. This doesn't give the application any chance to respond to the error. It's usually better to throw an error and allow the application to handle it appropriately:
if (somethingBadHappened) {
throw new Error("Something bad happened!");
}
By throwing an error in this way, other parts of the application have an opportunity to handle the error rather than stopping the application altogether. If the error bubbles all the way up to the process without being handled, then the process will exit and a non-zero exit code will returned, so the end result is the same.
Rule Details
This rule aims to prevent the use of process.exit()
in Node.js JavaScript. As such, it warns whenever process.exit()
is found in code.
Examples of incorrect code for this rule:
/*eslint no-process-exit: "error"*/
process.exit(1);
process.exit(0);
Examples of correct code for this rule:
/*eslint no-process-exit: "error"*/
Process.exit();
var exit = process.exit;
When Not To Use It
There may be a part of a Node.js application that is responsible for determining the correct exit code to return upon exiting. In that case, you should turn this rule off to allow proper handling of the exit code. Source: http://eslint.org/docs/rules/
Unexpected require(). Open
var pkgJson = require(path.resolve(__dirname, '../package.json'));
- Read upRead up
- Exclude checks
Enforce require() on the top-level module scope (global-require)
In Node.js, module dependencies are included using the require()
function, such as:
var fs = require("fs");
While require()
may be called anywhere in code, some style guides prescribe that it should be called only in the top level of a module to make it easier to identify dependencies. For instance, it's arguably harder to identify dependencies when they are deeply nested inside of functions and other statements:
function foo() {
if (condition) {
var fs = require("fs");
}
}
Since require()
does a synchronous load, it can cause performance problems when used in other locations.
Further, ES6 modules mandate that import
and export
statements can only occur in the top level of the module's body.
Rule Details
This rule requires all calls to require()
to be at the top level of the module, similar to ES6 import
and export
statements, which also can occur only at the top level.
Examples of incorrect code for this rule:
/*eslint global-require: "error"*/
/*eslint-env es6*/
// calling require() inside of a function is not allowed
function readFile(filename, callback) {
var fs = require('fs');
fs.readFile(filename, callback)
}
// conditional requires like this are also not allowed
if (DEBUG) { require('debug'); }
// a require() in a switch statement is also flagged
switch(x) { case '1': require('1'); break; }
// you may not require() inside an arrow function body
var getModule = (name) => require(name);
// you may not require() inside of a function body as well
function getModule(name) { return require(name); }
// you may not require() inside of a try/catch block
try {
require(unsafeModule);
} catch(e) {
console.log(e);
}
Examples of correct code for this rule:
/*eslint global-require: "error"*/
// all these variations of require() are ok
require('x');
var y = require('y');
var z;
z = require('z').initialize();
// requiring a module and using it in a function is ok
var fs = require('fs');
function readFile(filename, callback) {
fs.readFile(filename, callback)
}
// you can use a ternary to determine which module to require
var logger = DEBUG ? require('dev-logger') : require('logger');
// if you want you can require() at the end of your module
function doSomethingA() {}
function doSomethingB() {}
var x = require("x"),
z = require("z");
When Not To Use It
If you have a module that must be initialized with information that comes from the file-system or if a module is only used in very rare situations and will cause significant overhead to load it may make sense to disable the rule. If you need to require()
an optional dependency inside of a try
/catch
, you can disable this rule for just that dependency using the // eslint-disable-line global-require
comment.
Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
return s.id == id;
- 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/
Don't use process.exit(); throw an error instead. Open
process.exit(0);
- Read upRead up
- Exclude checks
Disallow process.exit() (no-process-exit)
The process.exit()
method in Node.js is used to immediately stop the Node.js process and exit. This is a dangerous operation because it can occur in any method at any point in time, potentially stopping a Node.js application completely when an error occurs. For example:
if (somethingBadHappened) {
console.error("Something bad happened!");
process.exit(1);
}
This code could appear in any module and will stop the entire application when somethingBadHappened
is truthy. This doesn't give the application any chance to respond to the error. It's usually better to throw an error and allow the application to handle it appropriately:
if (somethingBadHappened) {
throw new Error("Something bad happened!");
}
By throwing an error in this way, other parts of the application have an opportunity to handle the error rather than stopping the application altogether. If the error bubbles all the way up to the process without being handled, then the process will exit and a non-zero exit code will returned, so the end result is the same.
Rule Details
This rule aims to prevent the use of process.exit()
in Node.js JavaScript. As such, it warns whenever process.exit()
is found in code.
Examples of incorrect code for this rule:
/*eslint no-process-exit: "error"*/
process.exit(1);
process.exit(0);
Examples of correct code for this rule:
/*eslint no-process-exit: "error"*/
Process.exit();
var exit = process.exit;
When Not To Use It
There may be a part of a Node.js application that is responsible for determining the correct exit code to return upon exiting. In that case, you should turn this rule off to allow proper handling of the exit code. Source: http://eslint.org/docs/rules/
Unexpected require(). Open
var storage = require ('./providers/' + provider);
- Read upRead up
- Exclude checks
Enforce require() on the top-level module scope (global-require)
In Node.js, module dependencies are included using the require()
function, such as:
var fs = require("fs");
While require()
may be called anywhere in code, some style guides prescribe that it should be called only in the top level of a module to make it easier to identify dependencies. For instance, it's arguably harder to identify dependencies when they are deeply nested inside of functions and other statements:
function foo() {
if (condition) {
var fs = require("fs");
}
}
Since require()
does a synchronous load, it can cause performance problems when used in other locations.
Further, ES6 modules mandate that import
and export
statements can only occur in the top level of the module's body.
Rule Details
This rule requires all calls to require()
to be at the top level of the module, similar to ES6 import
and export
statements, which also can occur only at the top level.
Examples of incorrect code for this rule:
/*eslint global-require: "error"*/
/*eslint-env es6*/
// calling require() inside of a function is not allowed
function readFile(filename, callback) {
var fs = require('fs');
fs.readFile(filename, callback)
}
// conditional requires like this are also not allowed
if (DEBUG) { require('debug'); }
// a require() in a switch statement is also flagged
switch(x) { case '1': require('1'); break; }
// you may not require() inside an arrow function body
var getModule = (name) => require(name);
// you may not require() inside of a function body as well
function getModule(name) { return require(name); }
// you may not require() inside of a try/catch block
try {
require(unsafeModule);
} catch(e) {
console.log(e);
}
Examples of correct code for this rule:
/*eslint global-require: "error"*/
// all these variations of require() are ok
require('x');
var y = require('y');
var z;
z = require('z').initialize();
// requiring a module and using it in a function is ok
var fs = require('fs');
function readFile(filename, callback) {
fs.readFile(filename, callback)
}
// you can use a ternary to determine which module to require
var logger = DEBUG ? require('dev-logger') : require('logger');
// if you want you can require() at the end of your module
function doSomethingA() {}
function doSomethingB() {}
var x = require("x"),
z = require("z");
When Not To Use It
If you have a module that must be initialized with information that comes from the file-system or if a module is only used in very rare situations and will cause significant overhead to load it may make sense to disable the rule. If you need to require()
an optional dependency inside of a try
/catch
, you can disable this rule for just that dependency using the // eslint-disable-line global-require
comment.
Source: http://eslint.org/docs/rules/
Expected error to be handled. Open
storage.getServices(options, function(err, services){
- Read upRead up
- Exclude checks
Enforce Callback Error Handling (handle-callback-err)
In Node.js, a common pattern for dealing with asynchronous behavior is called the callback pattern.
This pattern expects an Error
object or null
as the first argument of the callback.
Forgetting to handle these errors can lead to some really strange behavior in your application.
function loadData (err, data) {
doSomething(); // forgot to handle error
}
Rule Details
This rule expects that when you're using the callback pattern in Node.js you'll handle the error.
Options
The rule takes a single string option: the name of the error parameter. The default is "err"
.
Examples of incorrect code for this rule with the default "err"
parameter name:
/*eslint handle-callback-err: "error"*/
function loadData (err, data) {
doSomething();
}
Examples of correct code for this rule with the default "err"
parameter name:
/*eslint handle-callback-err: "error"*/
function loadData (err, data) {
if (err) {
console.log(err.stack);
}
doSomething();
}
function generateError (err) {
if (err) {}
}
Examples of correct code for this rule with a sample "error"
parameter name:
/*eslint handle-callback-err: ["error", "error"]*/
function loadData (error, data) {
if (error) {
console.log(error.stack);
}
doSomething();
}
regular expression
Sometimes (especially in big projects) the name of the error variable is not consistent across the project, so you need a more flexible configuration to ensure that the rule reports all unhandled errors.
If the configured name of the error variable begins with a ^
it is considered to be a regexp pattern.
- If the option is
"^(err|error|anySpecificError)$"
, the rule reports unhandled errors where the parameter name can beerr
,error
oranySpecificError
. - If the option is
"^.+Error$"
, the rule reports unhandled errors where the parameter name ends withError
(for example,connectionError
orvalidationError
will match). - If the option is
"^.*(e|E)rr"
, the rule reports unhandled errors where the parameter name matches any string that containserr
orErr
(for example,err
,error
,anyError
,some_err
will match).
When Not To Use It
There are cases where it may be safe for your application to ignore errors, however only ignore errors if you are confident that some other form of monitoring will help you catch the problem.
Further Reading
Move the invocation into the parens that contain the function. Open
exports = module.exports = (function(){
- Read upRead up
- Exclude checks
Require IIFEs to be Wrapped (wrap-iife)
You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.
// function expression could be unwrapped
var x = function () { return { y: 1 };}();
// function declaration must be wrapped
function () { /* side effects */ }(); // SyntaxError
Rule Details
This rule requires all immediately-invoked function expressions to be wrapped in parentheses.
Options
This rule has two options, a string option and an object option.
String option:
-
"outside"
enforces always wrapping the call expression. The default is"outside"
. -
"inside"
enforces always wrapping the function expression. -
"any"
enforces always wrapping, but allows either style.
Object option:
-
"functionPrototypeMethods": true
additionally enforces wrapping function expressions invoked using.call
and.apply
. The default isfalse
.
outside
Examples of incorrect code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };})(); // wrapped function expression
Examples of correct code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
inside
Examples of incorrect code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };}()); // wrapped call expression
Examples of correct code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = (function () { return { y: 1 };})(); // wrapped function expression
any
Examples of incorrect code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = function () { return { y: 1 };}(); // unwrapped
Examples of correct code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
var x = (function () { return { y: 1 };})(); // wrapped function expression
functionPrototypeMethods
Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = function(){ foo(); }()
var x = (function(){ foo(); }())
var x = function(){ foo(); }.call(bar)
var x = (function(){ foo(); }.call(bar))
Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = (function(){ foo(); })()
var x = (function(){ foo(); }).call(bar)
Source: http://eslint.org/docs/rules/
Don't use process.exit(); throw an error instead. Open
return process.exit(RETURN_CODES.BAD_STORAGE);
- Read upRead up
- Exclude checks
Disallow process.exit() (no-process-exit)
The process.exit()
method in Node.js is used to immediately stop the Node.js process and exit. This is a dangerous operation because it can occur in any method at any point in time, potentially stopping a Node.js application completely when an error occurs. For example:
if (somethingBadHappened) {
console.error("Something bad happened!");
process.exit(1);
}
This code could appear in any module and will stop the entire application when somethingBadHappened
is truthy. This doesn't give the application any chance to respond to the error. It's usually better to throw an error and allow the application to handle it appropriately:
if (somethingBadHappened) {
throw new Error("Something bad happened!");
}
By throwing an error in this way, other parts of the application have an opportunity to handle the error rather than stopping the application altogether. If the error bubbles all the way up to the process without being handled, then the process will exit and a non-zero exit code will returned, so the end result is the same.
Rule Details
This rule aims to prevent the use of process.exit()
in Node.js JavaScript. As such, it warns whenever process.exit()
is found in code.
Examples of incorrect code for this rule:
/*eslint no-process-exit: "error"*/
process.exit(1);
process.exit(0);
Examples of correct code for this rule:
/*eslint no-process-exit: "error"*/
Process.exit();
var exit = process.exit;
When Not To Use It
There may be a part of a Node.js application that is responsible for determining the correct exit code to return upon exiting. In that case, you should turn this rule off to allow proper handling of the exit code. Source: http://eslint.org/docs/rules/
Expected return with your callback function. Open
callback(null, service.failureInterval);
- Read upRead up
- Exclude checks
Enforce Return After Callback (callback-return)
The callback pattern is at the heart of most I/O and event-driven programming in JavaScript.
function doSomething(err, callback) {
if (err) {
return callback(err);
}
callback();
}
To prevent calling the callback multiple times it is important to return
anytime the callback is triggered outside
of the main function body. Neglecting this technique often leads to issues where you do something more than once.
For example, in the case of an HTTP request, you may try to send HTTP headers more than once leading Node.js to throw
a Can't render headers after they are sent to the client.
error.
Rule Details
This rule is aimed at ensuring that callbacks used outside of the main function block are always part-of or immediately
preceding a return
statement. This rule decides what is a callback based on the name of the function being called.
Options
The rule takes a single option - an array of possible callback names - which may include object methods. The default callback names are callback
, cb
, next
.
Default callback names
Examples of incorrect code for this rule with the default ["callback", "cb", "next"]
option:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
callback(err);
}
callback();
}
Examples of correct code for this rule with the default ["callback", "cb", "next"]
option:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
return callback(err);
}
callback();
}
Supplied callback names
Examples of incorrect code for this rule with the option ["done", "send.error", "send.success"]
:
/*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/
function foo(err, done) {
if (err) {
done(err);
}
done();
}
function bar(err, send) {
if (err) {
send.error(err);
}
send.success();
}
Examples of correct code for this rule with the option ["done", "send.error", "send.success"]
:
/*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/
function foo(err, done) {
if (err) {
return done(err);
}
done();
}
function bar(err, send) {
if (err) {
return send.error(err);
}
send.success();
}
Known Limitations
Because it is difficult to understand the meaning of a program through static analysis, this rule has limitations:
- false negatives when this rule reports correct code, but the program calls the callback more than one time (which is incorrect behavior)
- false positives when this rule reports incorrect code, but the program calls the callback only one time (which is correct behavior)
Passing the callback by reference
The static analysis of this rule does not detect that the program calls the callback if it is an argument of a function (for example, setTimeout
).
Example of a false negative when this rule reports correct code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
setTimeout(callback, 0); // this is bad, but WILL NOT warn
}
callback();
}
Triggering the callback within a nested function
The static analysis of this rule does not detect that the program calls the callback from within a nested function or an immediately-invoked function expression (IIFE).
Example of a false negative when this rule reports correct code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
process.nextTick(function() {
return callback(); // this is bad, but WILL NOT warn
});
}
callback();
}
If/else statements
The static analysis of this rule does not detect that the program calls the callback only one time in each branch of an if
statement.
Example of a false positive when this rule reports incorrect code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
callback(err); // this is fine, but WILL warn
} else {
callback(); // this is fine, but WILL warn
}
}
When Not To Use It
There are some cases where you might want to call a callback function more than once. In those cases this rule may lead to incorrect behavior. In those cases you may want to reserve a special name for those callbacks and not include that in the list of callbacks that trigger warnings.
Further Reading
Related Rules
- [handle-callback-err](handle-callback-err.md) Source: http://eslint.org/docs/rules/
Move the invocation into the parens that contain the function. Open
exports = module.exports = (function () {
- Read upRead up
- Exclude checks
Require IIFEs to be Wrapped (wrap-iife)
You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.
// function expression could be unwrapped
var x = function () { return { y: 1 };}();
// function declaration must be wrapped
function () { /* side effects */ }(); // SyntaxError
Rule Details
This rule requires all immediately-invoked function expressions to be wrapped in parentheses.
Options
This rule has two options, a string option and an object option.
String option:
-
"outside"
enforces always wrapping the call expression. The default is"outside"
. -
"inside"
enforces always wrapping the function expression. -
"any"
enforces always wrapping, but allows either style.
Object option:
-
"functionPrototypeMethods": true
additionally enforces wrapping function expressions invoked using.call
and.apply
. The default isfalse
.
outside
Examples of incorrect code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };})(); // wrapped function expression
Examples of correct code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
inside
Examples of incorrect code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };}()); // wrapped call expression
Examples of correct code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = (function () { return { y: 1 };})(); // wrapped function expression
any
Examples of incorrect code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = function () { return { y: 1 };}(); // unwrapped
Examples of correct code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
var x = (function () { return { y: 1 };})(); // wrapped function expression
functionPrototypeMethods
Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = function(){ foo(); }()
var x = (function(){ foo(); }())
var x = function(){ foo(); }.call(bar)
var x = (function(){ foo(); }.call(bar))
Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = (function(){ foo(); })()
var x = (function(){ foo(); }).call(bar)
Source: http://eslint.org/docs/rules/
Unexpected require(). Open
var pingFactory = require('watchmen-ping-' + service.pingServiceName);
- Read upRead up
- Exclude checks
Enforce require() on the top-level module scope (global-require)
In Node.js, module dependencies are included using the require()
function, such as:
var fs = require("fs");
While require()
may be called anywhere in code, some style guides prescribe that it should be called only in the top level of a module to make it easier to identify dependencies. For instance, it's arguably harder to identify dependencies when they are deeply nested inside of functions and other statements:
function foo() {
if (condition) {
var fs = require("fs");
}
}
Since require()
does a synchronous load, it can cause performance problems when used in other locations.
Further, ES6 modules mandate that import
and export
statements can only occur in the top level of the module's body.
Rule Details
This rule requires all calls to require()
to be at the top level of the module, similar to ES6 import
and export
statements, which also can occur only at the top level.
Examples of incorrect code for this rule:
/*eslint global-require: "error"*/
/*eslint-env es6*/
// calling require() inside of a function is not allowed
function readFile(filename, callback) {
var fs = require('fs');
fs.readFile(filename, callback)
}
// conditional requires like this are also not allowed
if (DEBUG) { require('debug'); }
// a require() in a switch statement is also flagged
switch(x) { case '1': require('1'); break; }
// you may not require() inside an arrow function body
var getModule = (name) => require(name);
// you may not require() inside of a function body as well
function getModule(name) { return require(name); }
// you may not require() inside of a try/catch block
try {
require(unsafeModule);
} catch(e) {
console.log(e);
}
Examples of correct code for this rule:
/*eslint global-require: "error"*/
// all these variations of require() are ok
require('x');
var y = require('y');
var z;
z = require('z').initialize();
// requiring a module and using it in a function is ok
var fs = require('fs');
function readFile(filename, callback) {
fs.readFile(filename, callback)
}
// you can use a ternary to determine which module to require
var logger = DEBUG ? require('dev-logger') : require('logger');
// if you want you can require() at the end of your module
function doSomethingA() {}
function doSomethingB() {}
var x = require("x"),
z = require("z");
When Not To Use It
If you have a module that must be initialized with information that comes from the file-system or if a module is only used in very rare situations and will cause significant overhead to load it may make sense to disable the rule. If you need to require()
an optional dependency inside of a try
/catch
, you can disable this rule for just that dependency using the // eslint-disable-line global-require
comment.
Source: http://eslint.org/docs/rules/
Expected return with your callback function. Open
callback(null, service.failureInterval);
- Read upRead up
- Exclude checks
Enforce Return After Callback (callback-return)
The callback pattern is at the heart of most I/O and event-driven programming in JavaScript.
function doSomething(err, callback) {
if (err) {
return callback(err);
}
callback();
}
To prevent calling the callback multiple times it is important to return
anytime the callback is triggered outside
of the main function body. Neglecting this technique often leads to issues where you do something more than once.
For example, in the case of an HTTP request, you may try to send HTTP headers more than once leading Node.js to throw
a Can't render headers after they are sent to the client.
error.
Rule Details
This rule is aimed at ensuring that callbacks used outside of the main function block are always part-of or immediately
preceding a return
statement. This rule decides what is a callback based on the name of the function being called.
Options
The rule takes a single option - an array of possible callback names - which may include object methods. The default callback names are callback
, cb
, next
.
Default callback names
Examples of incorrect code for this rule with the default ["callback", "cb", "next"]
option:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
callback(err);
}
callback();
}
Examples of correct code for this rule with the default ["callback", "cb", "next"]
option:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
return callback(err);
}
callback();
}
Supplied callback names
Examples of incorrect code for this rule with the option ["done", "send.error", "send.success"]
:
/*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/
function foo(err, done) {
if (err) {
done(err);
}
done();
}
function bar(err, send) {
if (err) {
send.error(err);
}
send.success();
}
Examples of correct code for this rule with the option ["done", "send.error", "send.success"]
:
/*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/
function foo(err, done) {
if (err) {
return done(err);
}
done();
}
function bar(err, send) {
if (err) {
return send.error(err);
}
send.success();
}
Known Limitations
Because it is difficult to understand the meaning of a program through static analysis, this rule has limitations:
- false negatives when this rule reports correct code, but the program calls the callback more than one time (which is incorrect behavior)
- false positives when this rule reports incorrect code, but the program calls the callback only one time (which is correct behavior)
Passing the callback by reference
The static analysis of this rule does not detect that the program calls the callback if it is an argument of a function (for example, setTimeout
).
Example of a false negative when this rule reports correct code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
setTimeout(callback, 0); // this is bad, but WILL NOT warn
}
callback();
}
Triggering the callback within a nested function
The static analysis of this rule does not detect that the program calls the callback from within a nested function or an immediately-invoked function expression (IIFE).
Example of a false negative when this rule reports correct code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
process.nextTick(function() {
return callback(); // this is bad, but WILL NOT warn
});
}
callback();
}
If/else statements
The static analysis of this rule does not detect that the program calls the callback only one time in each branch of an if
statement.
Example of a false positive when this rule reports incorrect code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
callback(err); // this is fine, but WILL warn
} else {
callback(); // this is fine, but WILL warn
}
}
When Not To Use It
There are some cases where you might want to call a callback function more than once. In those cases this rule may lead to incorrect behavior. In those cases you may want to reserve a special name for those callbacks and not include that in the list of callbacks that trigger warnings.
Further Reading
Related Rules
- [handle-callback-err](handle-callback-err.md) Source: http://eslint.org/docs/rules/
Move the invocation into the parens that contain the function. Open
exports = module.exports = (function(){
- Read upRead up
- Exclude checks
Require IIFEs to be Wrapped (wrap-iife)
You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.
// function expression could be unwrapped
var x = function () { return { y: 1 };}();
// function declaration must be wrapped
function () { /* side effects */ }(); // SyntaxError
Rule Details
This rule requires all immediately-invoked function expressions to be wrapped in parentheses.
Options
This rule has two options, a string option and an object option.
String option:
-
"outside"
enforces always wrapping the call expression. The default is"outside"
. -
"inside"
enforces always wrapping the function expression. -
"any"
enforces always wrapping, but allows either style.
Object option:
-
"functionPrototypeMethods": true
additionally enforces wrapping function expressions invoked using.call
and.apply
. The default isfalse
.
outside
Examples of incorrect code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };})(); // wrapped function expression
Examples of correct code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
inside
Examples of incorrect code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };}()); // wrapped call expression
Examples of correct code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = (function () { return { y: 1 };})(); // wrapped function expression
any
Examples of incorrect code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = function () { return { y: 1 };}(); // unwrapped
Examples of correct code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
var x = (function () { return { y: 1 };})(); // wrapped function expression
functionPrototypeMethods
Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = function(){ foo(); }()
var x = (function(){ foo(); }())
var x = function(){ foo(); }.call(bar)
var x = (function(){ foo(); }.call(bar))
Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = (function(){ foo(); })()
var x = (function(){ foo(); }).call(bar)
Source: http://eslint.org/docs/rules/
Expected error to be handled. Open
reporter.getService(program.serviceId, function(err, service){
- Read upRead up
- Exclude checks
Enforce Callback Error Handling (handle-callback-err)
In Node.js, a common pattern for dealing with asynchronous behavior is called the callback pattern.
This pattern expects an Error
object or null
as the first argument of the callback.
Forgetting to handle these errors can lead to some really strange behavior in your application.
function loadData (err, data) {
doSomething(); // forgot to handle error
}
Rule Details
This rule expects that when you're using the callback pattern in Node.js you'll handle the error.
Options
The rule takes a single string option: the name of the error parameter. The default is "err"
.
Examples of incorrect code for this rule with the default "err"
parameter name:
/*eslint handle-callback-err: "error"*/
function loadData (err, data) {
doSomething();
}
Examples of correct code for this rule with the default "err"
parameter name:
/*eslint handle-callback-err: "error"*/
function loadData (err, data) {
if (err) {
console.log(err.stack);
}
doSomething();
}
function generateError (err) {
if (err) {}
}
Examples of correct code for this rule with a sample "error"
parameter name:
/*eslint handle-callback-err: ["error", "error"]*/
function loadData (error, data) {
if (error) {
console.log(error.stack);
}
doSomething();
}
regular expression
Sometimes (especially in big projects) the name of the error variable is not consistent across the project, so you need a more flexible configuration to ensure that the rule reports all unhandled errors.
If the configured name of the error variable begins with a ^
it is considered to be a regexp pattern.
- If the option is
"^(err|error|anySpecificError)$"
, the rule reports unhandled errors where the parameter name can beerr
,error
oranySpecificError
. - If the option is
"^.+Error$"
, the rule reports unhandled errors where the parameter name ends withError
(for example,connectionError
orvalidationError
will match). - If the option is
"^.*(e|E)rr"
, the rule reports unhandled errors where the parameter name matches any string that containserr
orErr
(for example,err
,error
,anyError
,some_err
will match).
When Not To Use It
There are cases where it may be safe for your application to ignore errors, however only ignore errors if you are confident that some other form of monitoring will help you catch the problem.
Further Reading
Move the invocation into the parens that contain the function. Open
var addSorting = (function () {
- Read upRead up
- Exclude checks
Require IIFEs to be Wrapped (wrap-iife)
You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.
// function expression could be unwrapped
var x = function () { return { y: 1 };}();
// function declaration must be wrapped
function () { /* side effects */ }(); // SyntaxError
Rule Details
This rule requires all immediately-invoked function expressions to be wrapped in parentheses.
Options
This rule has two options, a string option and an object option.
String option:
-
"outside"
enforces always wrapping the call expression. The default is"outside"
. -
"inside"
enforces always wrapping the function expression. -
"any"
enforces always wrapping, but allows either style.
Object option:
-
"functionPrototypeMethods": true
additionally enforces wrapping function expressions invoked using.call
and.apply
. The default isfalse
.
outside
Examples of incorrect code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };})(); // wrapped function expression
Examples of correct code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
inside
Examples of incorrect code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };}()); // wrapped call expression
Examples of correct code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = (function () { return { y: 1 };})(); // wrapped function expression
any
Examples of incorrect code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = function () { return { y: 1 };}(); // unwrapped
Examples of correct code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
var x = (function () { return { y: 1 };})(); // wrapped function expression
functionPrototypeMethods
Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = function(){ foo(); }()
var x = (function(){ foo(); }())
var x = function(){ foo(); }.call(bar)
var x = (function(){ foo(); }.call(bar))
Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = (function(){ foo(); })()
var x = (function(){ foo(); }).call(bar)
Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if (pos == -1) {
- 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/
Unexpected require(). Open
services = require('../../test/fixtures/real-services');
- Read upRead up
- Exclude checks
Enforce require() on the top-level module scope (global-require)
In Node.js, module dependencies are included using the require()
function, such as:
var fs = require("fs");
While require()
may be called anywhere in code, some style guides prescribe that it should be called only in the top level of a module to make it easier to identify dependencies. For instance, it's arguably harder to identify dependencies when they are deeply nested inside of functions and other statements:
function foo() {
if (condition) {
var fs = require("fs");
}
}
Since require()
does a synchronous load, it can cause performance problems when used in other locations.
Further, ES6 modules mandate that import
and export
statements can only occur in the top level of the module's body.
Rule Details
This rule requires all calls to require()
to be at the top level of the module, similar to ES6 import
and export
statements, which also can occur only at the top level.
Examples of incorrect code for this rule:
/*eslint global-require: "error"*/
/*eslint-env es6*/
// calling require() inside of a function is not allowed
function readFile(filename, callback) {
var fs = require('fs');
fs.readFile(filename, callback)
}
// conditional requires like this are also not allowed
if (DEBUG) { require('debug'); }
// a require() in a switch statement is also flagged
switch(x) { case '1': require('1'); break; }
// you may not require() inside an arrow function body
var getModule = (name) => require(name);
// you may not require() inside of a function body as well
function getModule(name) { return require(name); }
// you may not require() inside of a try/catch block
try {
require(unsafeModule);
} catch(e) {
console.log(e);
}
Examples of correct code for this rule:
/*eslint global-require: "error"*/
// all these variations of require() are ok
require('x');
var y = require('y');
var z;
z = require('z').initialize();
// requiring a module and using it in a function is ok
var fs = require('fs');
function readFile(filename, callback) {
fs.readFile(filename, callback)
}
// you can use a ternary to determine which module to require
var logger = DEBUG ? require('dev-logger') : require('logger');
// if you want you can require() at the end of your module
function doSomethingA() {}
function doSomethingB() {}
var x = require("x"),
z = require("z");
When Not To Use It
If you have a module that must be initialized with information that comes from the file-system or if a module is only used in very rare situations and will cause significant overhead to load it may make sense to disable the rule. If you need to require()
an optional dependency inside of a try
/catch
, you can disable this rule for just that dependency using the // eslint-disable-line global-require
comment.
Source: http://eslint.org/docs/rules/
Move the invocation into the parens that contain the function. Open
exports = module.exports = (function(){
- Read upRead up
- Exclude checks
Require IIFEs to be Wrapped (wrap-iife)
You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.
// function expression could be unwrapped
var x = function () { return { y: 1 };}();
// function declaration must be wrapped
function () { /* side effects */ }(); // SyntaxError
Rule Details
This rule requires all immediately-invoked function expressions to be wrapped in parentheses.
Options
This rule has two options, a string option and an object option.
String option:
-
"outside"
enforces always wrapping the call expression. The default is"outside"
. -
"inside"
enforces always wrapping the function expression. -
"any"
enforces always wrapping, but allows either style.
Object option:
-
"functionPrototypeMethods": true
additionally enforces wrapping function expressions invoked using.call
and.apply
. The default isfalse
.
outside
Examples of incorrect code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };})(); // wrapped function expression
Examples of correct code for the default "outside"
option:
/*eslint wrap-iife: ["error", "outside"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
inside
Examples of incorrect code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };}()); // wrapped call expression
Examples of correct code for the "inside"
option:
/*eslint wrap-iife: ["error", "inside"]*/
var x = (function () { return { y: 1 };})(); // wrapped function expression
any
Examples of incorrect code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = function () { return { y: 1 };}(); // unwrapped
Examples of correct code for the "any"
option:
/*eslint wrap-iife: ["error", "any"]*/
var x = (function () { return { y: 1 };}()); // wrapped call expression
var x = (function () { return { y: 1 };})(); // wrapped function expression
functionPrototypeMethods
Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = function(){ foo(); }()
var x = (function(){ foo(); }())
var x = function(){ foo(); }.call(bar)
var x = (function(){ foo(); }.call(bar))
Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true }
options:
/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
var x = (function(){ foo(); })()
var x = (function(){ foo(); }).call(bar)
Source: http://eslint.org/docs/rules/
Expected return with your callback function. Open
callback(null, parsedData);
- Read upRead up
- Exclude checks
Enforce Return After Callback (callback-return)
The callback pattern is at the heart of most I/O and event-driven programming in JavaScript.
function doSomething(err, callback) {
if (err) {
return callback(err);
}
callback();
}
To prevent calling the callback multiple times it is important to return
anytime the callback is triggered outside
of the main function body. Neglecting this technique often leads to issues where you do something more than once.
For example, in the case of an HTTP request, you may try to send HTTP headers more than once leading Node.js to throw
a Can't render headers after they are sent to the client.
error.
Rule Details
This rule is aimed at ensuring that callbacks used outside of the main function block are always part-of or immediately
preceding a return
statement. This rule decides what is a callback based on the name of the function being called.
Options
The rule takes a single option - an array of possible callback names - which may include object methods. The default callback names are callback
, cb
, next
.
Default callback names
Examples of incorrect code for this rule with the default ["callback", "cb", "next"]
option:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
callback(err);
}
callback();
}
Examples of correct code for this rule with the default ["callback", "cb", "next"]
option:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
return callback(err);
}
callback();
}
Supplied callback names
Examples of incorrect code for this rule with the option ["done", "send.error", "send.success"]
:
/*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/
function foo(err, done) {
if (err) {
done(err);
}
done();
}
function bar(err, send) {
if (err) {
send.error(err);
}
send.success();
}
Examples of correct code for this rule with the option ["done", "send.error", "send.success"]
:
/*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/
function foo(err, done) {
if (err) {
return done(err);
}
done();
}
function bar(err, send) {
if (err) {
return send.error(err);
}
send.success();
}
Known Limitations
Because it is difficult to understand the meaning of a program through static analysis, this rule has limitations:
- false negatives when this rule reports correct code, but the program calls the callback more than one time (which is incorrect behavior)
- false positives when this rule reports incorrect code, but the program calls the callback only one time (which is correct behavior)
Passing the callback by reference
The static analysis of this rule does not detect that the program calls the callback if it is an argument of a function (for example, setTimeout
).
Example of a false negative when this rule reports correct code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
setTimeout(callback, 0); // this is bad, but WILL NOT warn
}
callback();
}
Triggering the callback within a nested function
The static analysis of this rule does not detect that the program calls the callback from within a nested function or an immediately-invoked function expression (IIFE).
Example of a false negative when this rule reports correct code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
process.nextTick(function() {
return callback(); // this is bad, but WILL NOT warn
});
}
callback();
}
If/else statements
The static analysis of this rule does not detect that the program calls the callback only one time in each branch of an if
statement.
Example of a false positive when this rule reports incorrect code:
/*eslint callback-return: "error"*/
function foo(err, callback) {
if (err) {
callback(err); // this is fine, but WILL warn
} else {
callback(); // this is fine, but WILL warn
}
}
When Not To Use It
There are some cases where you might want to call a callback function more than once. In those cases this rule may lead to incorrect behavior. In those cases you may want to reserve a special name for those callbacks and not include that in the list of callbacks that trigger warnings.
Further Reading
Related Rules
- [handle-callback-err](handle-callback-err.md) Source: http://eslint.org/docs/rules/
TODO found Open
- Addressing one if the items on the TODO list or one of the open issues.
- Exclude checks