Showing 179 of 179 total issues
The function binding is unnecessary. Open
}.bind(this), function (error) {
- Read upRead up
- Exclude checks
Disallow unnecessary function binding (no-extra-bind)
The bind()
method is used to create functions with specific this
values and, optionally, binds arguments to specific values. When used to specify the value of this
, it's important that the function actually use this
in its function body. For example:
var boundGetName = (function getName() {
return this.name;
}).bind({ name: "ESLint" });
console.log(boundGetName()); // "ESLint"
This code is an example of a good use of bind()
for setting the value of this
.
Sometimes during the course of code maintenance, the this
value is removed from the function body. In that case, you can end up with a call to bind()
that doesn't accomplish anything:
// useless bind
var boundGetName = (function getName() {
return "ESLint";
}).bind({ name: "ESLint" });
console.log(boundGetName()); // "ESLint"
In this code, the reference to this
has been removed but bind()
is still used. In this case, the bind()
is unnecessary overhead (and a performance hit) and can be safely removed.
Rule Details
This rule is aimed at avoiding the unnecessary use of bind()
and as such will warn whenever an immediately-invoked function expression (IIFE) is using bind()
and doesn't have an appropriate this
value. This rule won't flag usage of bind()
that includes function argument binding.
Note: Arrow functions can never have their this
value set using bind()
. This rule flags all uses of bind()
with arrow functions as a problem
Examples of incorrect code for this rule:
/*eslint no-extra-bind: "error"*/
/*eslint-env es6*/
var x = function () {
foo();
}.bind(bar);
var x = (() => {
foo();
}).bind(bar);
var x = (() => {
this.foo();
}).bind(bar);
var x = function () {
(function () {
this.foo();
}());
}.bind(bar);
var x = function () {
function foo() {
this.bar();
}
}.bind(baz);
Examples of correct code for this rule:
/*eslint no-extra-bind: "error"*/
var x = function () {
this.foo();
}.bind(bar);
var x = function (a) {
return a + 1;
}.bind(foo, bar);
When Not To Use It
If you are not concerned about unnecessary calls to bind()
, you can safely disable this rule.
Further Reading
The function binding is unnecessary. Open
}.bind(this));
- Read upRead up
- Exclude checks
Disallow unnecessary function binding (no-extra-bind)
The bind()
method is used to create functions with specific this
values and, optionally, binds arguments to specific values. When used to specify the value of this
, it's important that the function actually use this
in its function body. For example:
var boundGetName = (function getName() {
return this.name;
}).bind({ name: "ESLint" });
console.log(boundGetName()); // "ESLint"
This code is an example of a good use of bind()
for setting the value of this
.
Sometimes during the course of code maintenance, the this
value is removed from the function body. In that case, you can end up with a call to bind()
that doesn't accomplish anything:
// useless bind
var boundGetName = (function getName() {
return "ESLint";
}).bind({ name: "ESLint" });
console.log(boundGetName()); // "ESLint"
In this code, the reference to this
has been removed but bind()
is still used. In this case, the bind()
is unnecessary overhead (and a performance hit) and can be safely removed.
Rule Details
This rule is aimed at avoiding the unnecessary use of bind()
and as such will warn whenever an immediately-invoked function expression (IIFE) is using bind()
and doesn't have an appropriate this
value. This rule won't flag usage of bind()
that includes function argument binding.
Note: Arrow functions can never have their this
value set using bind()
. This rule flags all uses of bind()
with arrow functions as a problem
Examples of incorrect code for this rule:
/*eslint no-extra-bind: "error"*/
/*eslint-env es6*/
var x = function () {
foo();
}.bind(bar);
var x = (() => {
foo();
}).bind(bar);
var x = (() => {
this.foo();
}).bind(bar);
var x = function () {
(function () {
this.foo();
}());
}.bind(bar);
var x = function () {
function foo() {
this.bar();
}
}.bind(baz);
Examples of correct code for this rule:
/*eslint no-extra-bind: "error"*/
var x = function () {
this.foo();
}.bind(bar);
var x = function (a) {
return a + 1;
}.bind(foo, bar);
When Not To Use It
If you are not concerned about unnecessary calls to bind()
, you can safely disable this rule.
Further Reading
The function binding is unnecessary. Open
}.bind(this) , function () {
- Read upRead up
- Exclude checks
Disallow unnecessary function binding (no-extra-bind)
The bind()
method is used to create functions with specific this
values and, optionally, binds arguments to specific values. When used to specify the value of this
, it's important that the function actually use this
in its function body. For example:
var boundGetName = (function getName() {
return this.name;
}).bind({ name: "ESLint" });
console.log(boundGetName()); // "ESLint"
This code is an example of a good use of bind()
for setting the value of this
.
Sometimes during the course of code maintenance, the this
value is removed from the function body. In that case, you can end up with a call to bind()
that doesn't accomplish anything:
// useless bind
var boundGetName = (function getName() {
return "ESLint";
}).bind({ name: "ESLint" });
console.log(boundGetName()); // "ESLint"
In this code, the reference to this
has been removed but bind()
is still used. In this case, the bind()
is unnecessary overhead (and a performance hit) and can be safely removed.
Rule Details
This rule is aimed at avoiding the unnecessary use of bind()
and as such will warn whenever an immediately-invoked function expression (IIFE) is using bind()
and doesn't have an appropriate this
value. This rule won't flag usage of bind()
that includes function argument binding.
Note: Arrow functions can never have their this
value set using bind()
. This rule flags all uses of bind()
with arrow functions as a problem
Examples of incorrect code for this rule:
/*eslint no-extra-bind: "error"*/
/*eslint-env es6*/
var x = function () {
foo();
}.bind(bar);
var x = (() => {
foo();
}).bind(bar);
var x = (() => {
this.foo();
}).bind(bar);
var x = function () {
(function () {
this.foo();
}());
}.bind(bar);
var x = function () {
function foo() {
this.bar();
}
}.bind(baz);
Examples of correct code for this rule:
/*eslint no-extra-bind: "error"*/
var x = function () {
this.foo();
}.bind(bar);
var x = function (a) {
return a + 1;
}.bind(foo, bar);
When Not To Use It
If you are not concerned about unnecessary calls to bind()
, you can safely disable this rule.
Further Reading
Expected return with your callback function. Open
next();
- 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/
Parsing error: Unexpected token function Open
function ($rootScope, logService, appConstants, $translate, $scope, moment) {
- Read upRead up
- Exclude checks
For more information visit 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/
Expected return with your callback function. Open
next();
- 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/
Expected return with your callback function. Open
next();
- 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/
unnecessary '.call()'. Open
this[type].call(this, params);
- Read upRead up
- Exclude checks
Disallow unnecessary .call()
and .apply()
. (no-useless-call)
The function invocation can be written by Function.prototype.call()
and Function.prototype.apply()
.
But Function.prototype.call()
and Function.prototype.apply()
are slower than the normal function invocation.
Rule Details
This rule is aimed to flag usage of Function.prototype.call()
and Function.prototype.apply()
that can be replaced with the normal function invocation.
Examples of incorrect code for this rule:
/*eslint no-useless-call: "error"*/
// These are same as `foo(1, 2, 3);`
foo.call(undefined, 1, 2, 3);
foo.apply(undefined, [1, 2, 3]);
foo.call(null, 1, 2, 3);
foo.apply(null, [1, 2, 3]);
// These are same as `obj.foo(1, 2, 3);`
obj.foo.call(obj, 1, 2, 3);
obj.foo.apply(obj, [1, 2, 3]);
Examples of correct code for this rule:
/*eslint no-useless-call: "error"*/
// The `this` binding is different.
foo.call(obj, 1, 2, 3);
foo.apply(obj, [1, 2, 3]);
obj.foo.call(null, 1, 2, 3);
obj.foo.apply(null, [1, 2, 3]);
obj.foo.call(otherObj, 1, 2, 3);
obj.foo.apply(otherObj, [1, 2, 3]);
// The argument list is variadic.
foo.apply(undefined, args);
foo.apply(null, args);
obj.foo.apply(obj, args);
Known Limitations
This rule compares code statically to check whether or not thisArg
is changed.
So if the code about thisArg
is a dynamic expression, this rule cannot judge correctly.
Examples of incorrect code for this rule:
/*eslint no-useless-call: "error"*/
a[i++].foo.call(a[i++], 1, 2, 3);
Examples of correct code for this rule:
/*eslint no-useless-call: "error"*/
a[++i].foo.call(a[i], 1, 2, 3);
When Not To Use It
If you don't want to be notified about unnecessary .call()
and .apply()
, you can safely 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/
Expected return with your callback function. Open
next();
- 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/
Irregular whitespace not allowed. Open
'x-origin-ip' : _.isEmpty(clientIp) || _.isUndefined(clientIp) ? '' : clientIp,
- Read upRead up
- Exclude checks
disallow irregular whitespace (no-irregular-whitespace)
Invalid or irregular whitespace causes issues with ECMAScript 5 parsers and also makes code harder to debug in a similar nature to mixed tabs and spaces.
Various whitespace characters can be inputted by programmers by mistake for example from copying or keyboard shortcuts. Pressing Alt + Space on OS X adds in a non breaking space character for example.
Known issues these spaces cause:
- Zero Width Space
- Is NOT considered a separator for tokens and is often parsed as an
Unexpected token ILLEGAL
- Is NOT shown in modern browsers making code repository software expected to resolve the visualisation
- Is NOT considered a separator for tokens and is often parsed as an
- Line Separator
- Is NOT a valid character within JSON which would cause parse errors
Rule Details
This rule is aimed at catching invalid whitespace that is not a normal tab and space. Some of these characters may cause issues in modern browsers and others will be a debugging issue to spot.
This rule disallows the following characters except where the options allow:
\u000B - Line Tabulation (\v) - <vt>
\u000C - Form Feed (\f) - <ff>
\u00A0 - No-Break Space - <nbsp>
\u0085 - Next Line
\u1680 - Ogham Space Mark
\u180E - Mongolian Vowel Separator - <mvs>
\ufeff - Zero Width No-Break Space - <bom>
\u2000 - En Quad
\u2001 - Em Quad
\u2002 - En Space - <ensp>
\u2003 - Em Space - <emsp>
\u2004 - Tree-Per-Em
\u2005 - Four-Per-Em
\u2006 - Six-Per-Em
\u2007 - Figure Space
\u2008 - Punctuation Space - <puncsp>
\u2009 - Thin Space
\u200A - Hair Space
\u200B - Zero Width Space - <zwsp>
\u2028 - Line Separator
\u2029 - Paragraph Separator
\u202F - Narrow No-Break Space
\u205f - Medium Mathematical Space
\u3000 - Ideographic Space</zwsp></puncsp></emsp></ensp></bom></mvs></nbsp></ff></vt>
Options
This rule has an object option for exceptions:
-
"skipStrings": true
(default) allows any whitespace characters in string literals -
"skipComments": true
allows any whitespace characters in comments -
"skipRegExps": true
allows any whitespace characters in regular expression literals -
"skipTemplates": true
allows any whitespace characters in template literals
skipStrings
Examples of incorrect code for this rule with the default { "skipStrings": true }
option:
/*eslint no-irregular-whitespace: "error"*/
function thing() /*<nbsp>*/{
return 'test';
}
function thing( /*<nbsp>*/){
return 'test';
}
function thing /*<nbsp>*/(){
return 'test';
}
function thing/*<mvs>*/(){
return 'test';
}
function thing() {
return 'test'; /*<ensp>*/
}
function thing() {
return 'test'; /*<nbsp>*/
}
function thing() {
// Description <nbsp>: some descriptive text
}
/*
Description <nbsp>: some descriptive text
*/
function thing() {
return / <nbsp>regexp/;
}
/*eslint-env es6*/
function thing() {
return `template <nbsp>string`;
}</nbsp></nbsp></nbsp></nbsp></nbsp></ensp></mvs></nbsp></nbsp></nbsp>
Examples of correct code for this rule with the default { "skipStrings": true }
option:
/*eslint no-irregular-whitespace: "error"*/
function thing() {
return ' <nbsp>thing';
}
function thing() {
return '<zwsp>thing';
}
function thing() {
return 'th <nbsp>ing';
}</nbsp></zwsp></nbsp>
skipComments
Examples of additional correct code for this rule with the { "skipComments": true }
option:
/*eslint no-irregular-whitespace: ["error", { "skipComments": true }]*/
function thing() {
// Description <nbsp>: some descriptive text
}
/*
Description <nbsp>: some descriptive text
*/</nbsp></nbsp>
skipRegExps
Examples of additional correct code for this rule with the { "skipRegExps": true }
option:
/*eslint no-irregular-whitespace: ["error", { "skipRegExps": true }]*/
function thing() {
return / <nbsp>regexp/;
}</nbsp>
skipTemplates
Examples of additional correct code for this rule with the { "skipTemplates": true }
option:
/*eslint no-irregular-whitespace: ["error", { "skipTemplates": true }]*/
/*eslint-env es6*/
function thing() {
return `template <nbsp>string`;
}</nbsp>
When Not To Use It
If you decide that you wish to use whitespace other than tabs and spaces outside of strings in your application.
Further Reading
Expected return with your callback function. Open
next();
- 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/
Irregular whitespace not allowed. Open
var dateFormat = format || "DD/MM/YYYY";
- Read upRead up
- Exclude checks
disallow irregular whitespace (no-irregular-whitespace)
Invalid or irregular whitespace causes issues with ECMAScript 5 parsers and also makes code harder to debug in a similar nature to mixed tabs and spaces.
Various whitespace characters can be inputted by programmers by mistake for example from copying or keyboard shortcuts. Pressing Alt + Space on OS X adds in a non breaking space character for example.
Known issues these spaces cause:
- Zero Width Space
- Is NOT considered a separator for tokens and is often parsed as an
Unexpected token ILLEGAL
- Is NOT shown in modern browsers making code repository software expected to resolve the visualisation
- Is NOT considered a separator for tokens and is often parsed as an
- Line Separator
- Is NOT a valid character within JSON which would cause parse errors
Rule Details
This rule is aimed at catching invalid whitespace that is not a normal tab and space. Some of these characters may cause issues in modern browsers and others will be a debugging issue to spot.
This rule disallows the following characters except where the options allow:
\u000B - Line Tabulation (\v) - <vt>
\u000C - Form Feed (\f) - <ff>
\u00A0 - No-Break Space - <nbsp>
\u0085 - Next Line
\u1680 - Ogham Space Mark
\u180E - Mongolian Vowel Separator - <mvs>
\ufeff - Zero Width No-Break Space - <bom>
\u2000 - En Quad
\u2001 - Em Quad
\u2002 - En Space - <ensp>
\u2003 - Em Space - <emsp>
\u2004 - Tree-Per-Em
\u2005 - Four-Per-Em
\u2006 - Six-Per-Em
\u2007 - Figure Space
\u2008 - Punctuation Space - <puncsp>
\u2009 - Thin Space
\u200A - Hair Space
\u200B - Zero Width Space - <zwsp>
\u2028 - Line Separator
\u2029 - Paragraph Separator
\u202F - Narrow No-Break Space
\u205f - Medium Mathematical Space
\u3000 - Ideographic Space</zwsp></puncsp></emsp></ensp></bom></mvs></nbsp></ff></vt>
Options
This rule has an object option for exceptions:
-
"skipStrings": true
(default) allows any whitespace characters in string literals -
"skipComments": true
allows any whitespace characters in comments -
"skipRegExps": true
allows any whitespace characters in regular expression literals -
"skipTemplates": true
allows any whitespace characters in template literals
skipStrings
Examples of incorrect code for this rule with the default { "skipStrings": true }
option:
/*eslint no-irregular-whitespace: "error"*/
function thing() /*<nbsp>*/{
return 'test';
}
function thing( /*<nbsp>*/){
return 'test';
}
function thing /*<nbsp>*/(){
return 'test';
}
function thing/*<mvs>*/(){
return 'test';
}
function thing() {
return 'test'; /*<ensp>*/
}
function thing() {
return 'test'; /*<nbsp>*/
}
function thing() {
// Description <nbsp>: some descriptive text
}
/*
Description <nbsp>: some descriptive text
*/
function thing() {
return / <nbsp>regexp/;
}
/*eslint-env es6*/
function thing() {
return `template <nbsp>string`;
}</nbsp></nbsp></nbsp></nbsp></nbsp></ensp></mvs></nbsp></nbsp></nbsp>
Examples of correct code for this rule with the default { "skipStrings": true }
option:
/*eslint no-irregular-whitespace: "error"*/
function thing() {
return ' <nbsp>thing';
}
function thing() {
return '<zwsp>thing';
}
function thing() {
return 'th <nbsp>ing';
}</nbsp></zwsp></nbsp>
skipComments
Examples of additional correct code for this rule with the { "skipComments": true }
option:
/*eslint no-irregular-whitespace: ["error", { "skipComments": true }]*/
function thing() {
// Description <nbsp>: some descriptive text
}
/*
Description <nbsp>: some descriptive text
*/</nbsp></nbsp>
skipRegExps
Examples of additional correct code for this rule with the { "skipRegExps": true }
option:
/*eslint no-irregular-whitespace: ["error", { "skipRegExps": true }]*/
function thing() {
return / <nbsp>regexp/;
}</nbsp>
skipTemplates
Examples of additional correct code for this rule with the { "skipTemplates": true }
option:
/*eslint no-irregular-whitespace: ["error", { "skipTemplates": true }]*/
/*eslint-env es6*/
function thing() {
return `template <nbsp>string`;
}</nbsp>
When Not To Use It
If you decide that you wish to use whitespace other than tabs and spaces outside of strings in your application.
Further Reading
Don't use process.exit(); throw an error instead. Open
process.exit(this.cfg.codes.fFailed);
- 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
next();
- 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/
Expected return with your callback function. Open
next();
- 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/
Don't use process.exit(); throw an error instead. Open
process.exit(this.cfg.codes.gFailed);
- 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 trailing comma. Open
'x-origin-host' : _.isUndefined(host) ? '' : host,
- Read upRead up
- Exclude checks
require or disallow trailing commas (comma-dangle)
Trailing commas in object literals are valid according to the ECMAScript 5 (and ECMAScript 3!) spec. However, IE8 (when not in IE8 document mode) and below will throw an error when it encounters trailing commas in JavaScript.
var foo = {
bar: "baz",
qux: "quux",
};
Trailing commas simplify adding and removing items to objects and arrays, since only the lines you are modifying must be touched. Another argument in favor of trailing commas is that it improves the clarity of diffs when an item is added or removed from an object or array:
Less clear:
var foo = {
- bar: "baz",
- qux: "quux"
+ bar: "baz"
};
More clear:
var foo = {
bar: "baz",
- qux: "quux",
};
Rule Details
This rule enforces consistent use of trailing commas in object and array literals.
Options
This rule has a string option or an object option:
{
"comma-dangle": ["error", "never"],
// or
"comma-dangle": ["error", {
"arrays": "never",
"objects": "never",
"imports": "never",
"exports": "never",
"functions": "ignore",
}]
}
-
"never"
(default) disallows trailing commas -
"always"
requires trailing commas -
"always-multiline"
requires trailing commas when the last element or property is in a different line than the closing]
or}
and disallows trailing commas when the last element or property is on the same line as the closing]
or}
-
"only-multiline"
allows (but does not require) trailing commas when the last element or property is in a different line than the closing]
or}
and disallows trailing commas when the last element or property is on the same line as the closing]
or}
Trailing commas in function declarations and function calls are valid syntax since ECMAScript 2017; however, the string option does not check these situations for backwards compatibility.
You can also use an object option to configure this rule for each type of syntax.
Each of the following options can be set to "never"
, "always"
, "always-multiline"
, "only-multiline"
, or "ignore"
.
The default for each option is "never"
unless otherwise specified.
-
arrays
is for array literals and array patterns of destructuring. (e.g.let [a,] = [1,];
) -
objects
is for object literals and object patterns of destructuring. (e.g.let {a,} = {a: 1};
) -
imports
is for import declarations of ES Modules. (e.g.import {a,} from "foo";
) -
exports
is for export declarations of ES Modules. (e.g.export {a,};
) -
functions
is for function declarations and function calls. (e.g.(function(a,){ })(b,);
)
functions
is set to"ignore"
by default for consistency with the string option.
never
Examples of incorrect code for this rule with the default "never"
option:
/*eslint comma-dangle: ["error", "never"]*/
var foo = {
bar: "baz",
qux: "quux",
};
var arr = [1,2,];
foo({
bar: "baz",
qux: "quux",
});
Examples of correct code for this rule with the default "never"
option:
/*eslint comma-dangle: ["error", "never"]*/
var foo = {
bar: "baz",
qux: "quux"
};
var arr = [1,2];
foo({
bar: "baz",
qux: "quux"
});
always
Examples of incorrect code for this rule with the "always"
option:
/*eslint comma-dangle: ["error", "always"]*/
var foo = {
bar: "baz",
qux: "quux"
};
var arr = [1,2];
foo({
bar: "baz",
qux: "quux"
});
Examples of correct code for this rule with the "always"
option:
/*eslint comma-dangle: ["error", "always"]*/
var foo = {
bar: "baz",
qux: "quux",
};
var arr = [1,2,];
foo({
bar: "baz",
qux: "quux",
});
always-multiline
Examples of incorrect code for this rule with the "always-multiline"
option:
/*eslint comma-dangle: ["error", "always-multiline"]*/
var foo = {
bar: "baz",
qux: "quux"
};
var foo = { bar: "baz", qux: "quux", };
var arr = [1,2,];
var arr = [1,
2,];
var arr = [
1,
2
];
foo({
bar: "baz",
qux: "quux"
});
Examples of correct code for this rule with the "always-multiline"
option:
/*eslint comma-dangle: ["error", "always-multiline"]*/
var foo = {
bar: "baz",
qux: "quux",
};
var foo = {bar: "baz", qux: "quux"};
var arr = [1,2];
var arr = [1,
2];
var arr = [
1,
2,
];
foo({
bar: "baz",
qux: "quux",
});
only-multiline
Examples of incorrect code for this rule with the "only-multiline"
option:
/*eslint comma-dangle: ["error", "only-multiline"]*/
var foo = { bar: "baz", qux: "quux", };
var arr = [1,2,];
var arr = [1,
2,];
Examples of correct code for this rule with the "only-multiline"
option:
/*eslint comma-dangle: ["error", "only-multiline"]*/
var foo = {
bar: "baz",
qux: "quux",
};
var foo = {
bar: "baz",
qux: "quux"
};
var foo = {bar: "baz", qux: "quux"};
var arr = [1,2];
var arr = [1,
2];
var arr = [
1,
2,
];
var arr = [
1,
2
];
foo({
bar: "baz",
qux: "quux",
});
foo({
bar: "baz",
qux: "quux"
});
functions
Examples of incorrect code for this rule with the {"functions": "never"}
option:
/*eslint comma-dangle: ["error", {"functions": "never"}]*/
function foo(a, b,) {
}
foo(a, b,);
new foo(a, b,);
Examples of correct code for this rule with the {"functions": "never"}
option:
/*eslint comma-dangle: ["error", {"functions": "never"}]*/
function foo(a, b) {
}
foo(a, b);
new foo(a, b);
Examples of incorrect code for this rule with the {"functions": "always"}
option:
/*eslint comma-dangle: ["error", {"functions": "always"}]*/
function foo(a, b) {
}
foo(a, b);
new foo(a, b);
Examples of correct code for this rule with the {"functions": "always"}
option:
/*eslint comma-dangle: ["error", {"functions": "always"}]*/
function foo(a, b,) {
}
foo(a, b,);
new foo(a, b,);
When Not To Use It
You can turn this rule off if you are not concerned with dangling commas. Source: http://eslint.org/docs/rules/