All 'var' declarations must be at the top of the function scope. Open
var opn = require('opn')
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Unexpected var, use let or const instead. Open
var opn = require('opn')
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var webpack = require('webpack')
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Missing semicolon. Open
require('./check-versions')()
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var port = process.env.PORT || config.dev.port
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var proxyTable = config.dev.proxyTable
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
All 'var' declarations must be at the top of the function scope. Open
var app = express()
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Missing semicolon. Open
var app = express()
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var express = require('express')
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Unexpected var, use let or const instead. Open
var proxyMiddleware = require('http-proxy-middleware')
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var compiler = webpack(webpackConfig)
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var port = process.env.PORT || config.dev.port
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Missing semicolon. Open
process.env.NODE_ENV = JSON.parse(config.dev.env.NODE_ENV)
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var app = express()
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var devMiddleware = require('webpack-dev-middleware')(compiler, {
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var config = require('../config')
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
All 'var' declarations must be at the top of the function scope. Open
var path = require('path')
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Missing semicolon. Open
var webpack = require('webpack')
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var proxyMiddleware = require('http-proxy-middleware')
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var autoOpenBrowser = !!config.dev.autoOpenBrowser
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var compiler = webpack(webpackConfig)
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
All 'var' declarations must be at the top of the function scope. Open
var proxyMiddleware = require('http-proxy-middleware')
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Missing semicolon. Open
var autoOpenBrowser = !!config.dev.autoOpenBrowser
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
})
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var config = require('../config')
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var webpackConfig = require('./webpack.dev.conf')
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Unexpected var, use let or const instead. Open
var port = process.env.PORT || config.dev.port
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var proxyTable = config.dev.proxyTable
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var path = require('path')
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var express = require('express')
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var config = require('../config')
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var webpack = require('webpack')
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var autoOpenBrowser = !!config.dev.autoOpenBrowser
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
All 'var' declarations must be at the top of the function scope. Open
var devMiddleware = require('webpack-dev-middleware')(compiler, {
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Missing semicolon. Open
var opn = require('opn')
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var path = require('path')
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var express = require('express')
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var webpackConfig = require('./webpack.dev.conf')
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var webpackConfig = require('./webpack.dev.conf')
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var proxyTable = config.dev.proxyTable
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var compiler = webpack(webpackConfig)
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected string concatenation. Open
var uri = 'http://localhost:' + port
- Read upRead up
- Exclude checks
Suggest using template literals instead of string concatenation. (prefer-template)
In ES2015 (ES6), we can use template literals instead of string concatenation.
var str = "Hello, " + name + "!";
/*eslint-env es6*/
var str = `Hello, ${name}!`;
Rule Details
This rule is aimed to flag usage of +
operators with strings.
Examples
Examples of incorrect code for this rule:
/*eslint prefer-template: "error"*/
var str = "Hello, " + name + "!";
var str = "Time: " + (12 * 60 * 60 * 1000);
Examples of correct code for this rule:
/*eslint prefer-template: "error"*/
/*eslint-env es6*/
var str = "Hello World!";
var str = `Hello, ${name}!`;
var str = `Time: ${12 * 60 * 60 * 1000}`;
// This is reported by `no-useless-concat`.
var str = "Hello, " + "World!";
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about string concatenation, you can safely disable this rule.
Related Rules
- [no-useless-concat](no-useless-concat.md)
- [quotes](quotes.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
app.use(hotMiddleware)
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
})
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected string concatenation. Open
console.log('> Listening at ' + uri + '\n')
- Read upRead up
- Exclude checks
Suggest using template literals instead of string concatenation. (prefer-template)
In ES2015 (ES6), we can use template literals instead of string concatenation.
var str = "Hello, " + name + "!";
/*eslint-env es6*/
var str = `Hello, ${name}!`;
Rule Details
This rule is aimed to flag usage of +
operators with strings.
Examples
Examples of incorrect code for this rule:
/*eslint prefer-template: "error"*/
var str = "Hello, " + name + "!";
var str = "Time: " + (12 * 60 * 60 * 1000);
Examples of correct code for this rule:
/*eslint prefer-template: "error"*/
/*eslint-env es6*/
var str = "Hello World!";
var str = `Hello, ${name}!`;
var str = `Time: ${12 * 60 * 60 * 1000}`;
// This is reported by `no-useless-concat`.
var str = "Hello, " + "World!";
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about string concatenation, you can safely disable this rule.
Related Rules
- [no-useless-concat](no-useless-concat.md)
- [quotes](quotes.md) Source: http://eslint.org/docs/rules/
Unexpected function expression. Open
module.exports = app.listen(port, function (err) {
- Read upRead up
- Exclude checks
Suggest using arrow functions as callbacks. (prefer-arrow-callback)
Arrow functions are suited to callbacks, because:
-
this
keywords in arrow functions bind to the upper scope's. - The notation of the arrow function is shorter than function expression's.
Rule Details
This rule is aimed to flag usage of function expressions in an argument list.
The following patterns are considered problems:
/*eslint prefer-arrow-callback: "error"*/
foo(function(a) { return a; });
foo(function() { return this.a; }.bind(this));
The following patterns are not considered problems:
/*eslint prefer-arrow-callback: "error"*/
/*eslint-env es6*/
foo(a => a);
foo(function*() { yield; });
// this is not a callback.
var foo = function foo(a) { return a; };
// using `this` without `.bind(this)`.
foo(function() { return this.a; });
// recursively.
foo(function bar(n) { return n && n + bar(n - 1); });
Options
This rule takes one optional argument, an object which is an options object.
allowNamedFunctions
This is a boolean
option and it is false
by default. When set to true
, the rule doesn't warn on named functions used as callbacks.
Examples of correct code for the { "allowNamedFunctions": true }
option:
/*eslint prefer-arrow-callback: ["error", { "allowNamedFunctions": true }]*/
foo(function bar() {});
allowUnboundThis
This is a boolean
option and it is true
by default. When set to false
, this option allows the use of this
without restriction and checks for dynamically assigned this
values such as when using Array.prototype.map
with a context
argument. Normally, the rule will flag the use of this
whenever a function does not use bind()
to specify the value of this
constantly.
Examples of incorrect code for the { "allowUnboundThis": false }
option:
/*eslint prefer-arrow-callback: ["error", { "allowUnboundThis": false }]*/
/*eslint-env es6*/
foo(function() { this.a; });
foo(function() { (() => this); });
someArray.map(function (itm) { return this.doSomething(itm); }, someObject);
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about function expressions in an argument list, you can safely disable this rule. Source: http://eslint.org/docs/rules/
Missing semicolon. Open
})
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
app.use(proxyMiddleware(options.filter || context, options))
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
hotMiddleware.publish({ action: 'reload' })
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
console.log(err)
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
})
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected unnamed function. Open
Object.keys(proxyTable).forEach(function (context) {
- Read upRead up
- Exclude checks
Require or disallow named function
expressions (func-names)
A pattern that's becoming more common is to give function expressions names to aid in debugging. For example:
Foo.prototype.bar = function bar() {};
Adding the second bar
in the above example is optional. If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function
in the stack trace. If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.
Rule Details
This rule can enforce or disallow the use of named function expressions.
Options
This rule has a string option:
-
"always"
(default) requires function expressions to have a name -
"as-needed"
requires function expressions to have a name, if the name cannot be assigned automatically in an ES6 environment -
"never"
disallows named function expressions, except in recursive functions, where a name is needed
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
as-needed
ECMAScript 6 introduced a name
property on all functions. The value of name
is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a name
property equal to the name of the variable. The value of name
is then used in stack traces for easier debugging.
Examples of incorrect code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
var bar = function() {};
(function bar() {
// ...
}())
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
Examples of correct code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Further Reading
Compatibility
- JSCS: requireAnonymousFunctions
- JSCS: disallowAnonymousFunctions Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var staticPath = path.posix.join(config.dev.assetsPublicPath, config.dev.assetsSubDirectory)
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Unexpected function expression. Open
devMiddleware.waitUntilValid(function () {
- Read upRead up
- Exclude checks
Suggest using arrow functions as callbacks. (prefer-arrow-callback)
Arrow functions are suited to callbacks, because:
-
this
keywords in arrow functions bind to the upper scope's. - The notation of the arrow function is shorter than function expression's.
Rule Details
This rule is aimed to flag usage of function expressions in an argument list.
The following patterns are considered problems:
/*eslint prefer-arrow-callback: "error"*/
foo(function(a) { return a; });
foo(function() { return this.a; }.bind(this));
The following patterns are not considered problems:
/*eslint prefer-arrow-callback: "error"*/
/*eslint-env es6*/
foo(a => a);
foo(function*() { yield; });
// this is not a callback.
var foo = function foo(a) { return a; };
// using `this` without `.bind(this)`.
foo(function() { return this.a; });
// recursively.
foo(function bar(n) { return n && n + bar(n - 1); });
Options
This rule takes one optional argument, an object which is an options object.
allowNamedFunctions
This is a boolean
option and it is false
by default. When set to true
, the rule doesn't warn on named functions used as callbacks.
Examples of correct code for the { "allowNamedFunctions": true }
option:
/*eslint prefer-arrow-callback: ["error", { "allowNamedFunctions": true }]*/
foo(function bar() {});
allowUnboundThis
This is a boolean
option and it is true
by default. When set to false
, this option allows the use of this
without restriction and checks for dynamically assigned this
values such as when using Array.prototype.map
with a context
argument. Normally, the rule will flag the use of this
whenever a function does not use bind()
to specify the value of this
constantly.
Examples of incorrect code for the { "allowUnboundThis": false }
option:
/*eslint prefer-arrow-callback: ["error", { "allowUnboundThis": false }]*/
/*eslint-env es6*/
foo(function() { this.a; });
foo(function() { (() => this); });
someArray.map(function (itm) { return this.doSomething(itm); }, someObject);
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about function expressions in an argument list, you can safely disable this rule. Source: http://eslint.org/docs/rules/
Missing semicolon. Open
return
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected function expression. Open
compiler.plugin('compilation', function (compilation) {
- Read upRead up
- Exclude checks
Suggest using arrow functions as callbacks. (prefer-arrow-callback)
Arrow functions are suited to callbacks, because:
-
this
keywords in arrow functions bind to the upper scope's. - The notation of the arrow function is shorter than function expression's.
Rule Details
This rule is aimed to flag usage of function expressions in an argument list.
The following patterns are considered problems:
/*eslint prefer-arrow-callback: "error"*/
foo(function(a) { return a; });
foo(function() { return this.a; }.bind(this));
The following patterns are not considered problems:
/*eslint prefer-arrow-callback: "error"*/
/*eslint-env es6*/
foo(a => a);
foo(function*() { yield; });
// this is not a callback.
var foo = function foo(a) { return a; };
// using `this` without `.bind(this)`.
foo(function() { return this.a; });
// recursively.
foo(function bar(n) { return n && n + bar(n - 1); });
Options
This rule takes one optional argument, an object which is an options object.
allowNamedFunctions
This is a boolean
option and it is false
by default. When set to true
, the rule doesn't warn on named functions used as callbacks.
Examples of correct code for the { "allowNamedFunctions": true }
option:
/*eslint prefer-arrow-callback: ["error", { "allowNamedFunctions": true }]*/
foo(function bar() {});
allowUnboundThis
This is a boolean
option and it is true
by default. When set to false
, this option allows the use of this
without restriction and checks for dynamically assigned this
values such as when using Array.prototype.map
with a context
argument. Normally, the rule will flag the use of this
whenever a function does not use bind()
to specify the value of this
constantly.
Examples of incorrect code for the { "allowUnboundThis": false }
option:
/*eslint prefer-arrow-callback: ["error", { "allowUnboundThis": false }]*/
/*eslint-env es6*/
foo(function() { this.a; });
foo(function() { (() => this); });
someArray.map(function (itm) { return this.doSomething(itm); }, someObject);
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about function expressions in an argument list, you can safely disable this rule. Source: http://eslint.org/docs/rules/
Missing semicolon. Open
})
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var uri = 'http://localhost:' + port
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var hotMiddleware = require('webpack-hot-middleware')(compiler, {
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Unexpected var, use let or const instead. Open
var staticPath = path.posix.join(config.dev.assetsPublicPath, config.dev.assetsSubDirectory)
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var hotMiddleware = require('webpack-hot-middleware')(compiler, {
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
Missing semicolon. Open
})
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var options = proxyTable[context]
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var uri = 'http://localhost:' + port
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected unnamed function. Open
compilation.plugin('html-webpack-plugin-after-emit', function (data, cb) {
- Read upRead up
- Exclude checks
Require or disallow named function
expressions (func-names)
A pattern that's becoming more common is to give function expressions names to aid in debugging. For example:
Foo.prototype.bar = function bar() {};
Adding the second bar
in the above example is optional. If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function
in the stack trace. If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.
Rule Details
This rule can enforce or disallow the use of named function expressions.
Options
This rule has a string option:
-
"always"
(default) requires function expressions to have a name -
"as-needed"
requires function expressions to have a name, if the name cannot be assigned automatically in an ES6 environment -
"never"
disallows named function expressions, except in recursive functions, where a name is needed
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
as-needed
ECMAScript 6 introduced a name
property on all functions. The value of name
is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a name
property equal to the name of the variable. The value of name
is then used in stack traces for easier debugging.
Examples of incorrect code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
var bar = function() {};
(function bar() {
// ...
}())
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
Examples of correct code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Further Reading
Compatibility
- JSCS: requireAnonymousFunctions
- JSCS: disallowAnonymousFunctions Source: http://eslint.org/docs/rules/
Missing semicolon. Open
app.use(devMiddleware)
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
console.log('> Listening at ' + uri + '\n')
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected unnamed function. Open
module.exports = app.listen(port, function (err) {
- Read upRead up
- Exclude checks
Require or disallow named function
expressions (func-names)
A pattern that's becoming more common is to give function expressions names to aid in debugging. For example:
Foo.prototype.bar = function bar() {};
Adding the second bar
in the above example is optional. If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function
in the stack trace. If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.
Rule Details
This rule can enforce or disallow the use of named function expressions.
Options
This rule has a string option:
-
"always"
(default) requires function expressions to have a name -
"as-needed"
requires function expressions to have a name, if the name cannot be assigned automatically in an ES6 environment -
"never"
disallows named function expressions, except in recursive functions, where a name is needed
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
as-needed
ECMAScript 6 introduced a name
property on all functions. The value of name
is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a name
property equal to the name of the variable. The value of name
is then used in stack traces for easier debugging.
Examples of incorrect code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
var bar = function() {};
(function bar() {
// ...
}())
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
Examples of correct code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Further Reading
Compatibility
- JSCS: requireAnonymousFunctions
- JSCS: disallowAnonymousFunctions Source: http://eslint.org/docs/rules/
Missing semicolon. Open
cb()
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected unnamed function. Open
compiler.plugin('compilation', function (compilation) {
- Read upRead up
- Exclude checks
Require or disallow named function
expressions (func-names)
A pattern that's becoming more common is to give function expressions names to aid in debugging. For example:
Foo.prototype.bar = function bar() {};
Adding the second bar
in the above example is optional. If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function
in the stack trace. If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.
Rule Details
This rule can enforce or disallow the use of named function expressions.
Options
This rule has a string option:
-
"always"
(default) requires function expressions to have a name -
"as-needed"
requires function expressions to have a name, if the name cannot be assigned automatically in an ES6 environment -
"never"
disallows named function expressions, except in recursive functions, where a name is needed
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
as-needed
ECMAScript 6 introduced a name
property on all functions. The value of name
is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a name
property equal to the name of the variable. The value of name
is then used in stack traces for easier debugging.
Examples of incorrect code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
var bar = function() {};
(function bar() {
// ...
}())
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
Examples of correct code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Further Reading
Compatibility
- JSCS: requireAnonymousFunctions
- JSCS: disallowAnonymousFunctions Source: http://eslint.org/docs/rules/
Missing semicolon. Open
var staticPath = path.posix.join(config.dev.assetsPublicPath, config.dev.assetsSubDirectory)
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
options = { target: options }
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
app.use(require('connect-history-api-fallback')())
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing semicolon. Open
app.use(staticPath, express.static('./static'))
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected var, use let or const instead. Open
var options = proxyTable[context]
- Read upRead up
- Exclude checks
require let
or const
instead of var
(no-var)
ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let
and const
keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes
such as:
var count = people.length;
var enoughFood = count > sandwiches.length;
if (enoughFood) {
var count = sandwiches.length; // accidentally overriding the count variable
console.log("We have " + count + " sandwiches for everyone. Plenty for all!");
}
// our count variable is no longer accurate
console.log("We have " + count + " people and " + sandwiches.length + " sandwiches!");
Rule Details
This rule is aimed at discouraging the use of var
and encouraging the use of const
or let
instead.
Examples
Examples of incorrect code for this rule:
/*eslint no-var: "error"*/
var x = "y";
var CONFIG = {};
Examples of correct code for this rule:
/*eslint no-var: "error"*/
/*eslint-env es6*/
let x = "y";
const CONFIG = {};
When Not To Use It
In addition to non-ES6 environments, existing JavaScript projects that are beginning to introduce ES6 into their
codebase may not want to apply this rule if the cost of migrating from var
to let
is too costly.
Source: http://eslint.org/docs/rules/
All 'var' declarations must be at the top of the function scope. Open
var uri = 'http://localhost:' + port
- Read upRead up
- Exclude checks
Require Variable Declarations to be at the top of their scope (vars-on-top)
The vars-on-top
rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
Rule Details
This rule aims to keep all variable declarations in the leading series of statements. Allowing multiple declarations helps promote maintainability and is thus allowed.
Examples of incorrect code for this rule:
/*eslint vars-on-top: "error"*/
// Variable declarations in a block:
function doSomething() {
var first;
if (true) {
first = true;
}
var second;
}
// Variable declaration in for initializer:
function doSomething() {
for (var i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
// Variables after other statements:
f();
var a;
Examples of correct code for this rule:
/*eslint vars-on-top: "error"*/
function doSomething() {
var first;
var second; //multiple declarations are allowed at the top
if (true) {
first = true;
}
}
function doSomething() {
var i;
for (i=0; i<10; i++) {}
}
/*eslint vars-on-top: "error"*/
var a;
f();
/*eslint vars-on-top: "error"*/
// Directives may precede variable declarations.
"use strict";
var a;
f();
// Comments can describe variables.
function doSomething() {
// this is the first var.
var first;
// this is the second var.
var second
}
Further Reading
Unexpected unnamed function. Open
devMiddleware.waitUntilValid(function () {
- Read upRead up
- Exclude checks
Require or disallow named function
expressions (func-names)
A pattern that's becoming more common is to give function expressions names to aid in debugging. For example:
Foo.prototype.bar = function bar() {};
Adding the second bar
in the above example is optional. If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function
in the stack trace. If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.
Rule Details
This rule can enforce or disallow the use of named function expressions.
Options
This rule has a string option:
-
"always"
(default) requires function expressions to have a name -
"as-needed"
requires function expressions to have a name, if the name cannot be assigned automatically in an ES6 environment -
"never"
disallows named function expressions, except in recursive functions, where a name is needed
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
as-needed
ECMAScript 6 introduced a name
property on all functions. The value of name
is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a name
property equal to the name of the variable. The value of name
is then used in stack traces for easier debugging.
Examples of incorrect code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
var bar = function() {};
(function bar() {
// ...
}())
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
Examples of correct code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Further Reading
Compatibility
- JSCS: requireAnonymousFunctions
- JSCS: disallowAnonymousFunctions Source: http://eslint.org/docs/rules/
Missing semicolon. Open
opn(uri)
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Unexpected function expression. Open
compilation.plugin('html-webpack-plugin-after-emit', function (data, cb) {
- Read upRead up
- Exclude checks
Suggest using arrow functions as callbacks. (prefer-arrow-callback)
Arrow functions are suited to callbacks, because:
-
this
keywords in arrow functions bind to the upper scope's. - The notation of the arrow function is shorter than function expression's.
Rule Details
This rule is aimed to flag usage of function expressions in an argument list.
The following patterns are considered problems:
/*eslint prefer-arrow-callback: "error"*/
foo(function(a) { return a; });
foo(function() { return this.a; }.bind(this));
The following patterns are not considered problems:
/*eslint prefer-arrow-callback: "error"*/
/*eslint-env es6*/
foo(a => a);
foo(function*() { yield; });
// this is not a callback.
var foo = function foo(a) { return a; };
// using `this` without `.bind(this)`.
foo(function() { return this.a; });
// recursively.
foo(function bar(n) { return n && n + bar(n - 1); });
Options
This rule takes one optional argument, an object which is an options object.
allowNamedFunctions
This is a boolean
option and it is false
by default. When set to true
, the rule doesn't warn on named functions used as callbacks.
Examples of correct code for the { "allowNamedFunctions": true }
option:
/*eslint prefer-arrow-callback: ["error", { "allowNamedFunctions": true }]*/
foo(function bar() {});
allowUnboundThis
This is a boolean
option and it is true
by default. When set to false
, this option allows the use of this
without restriction and checks for dynamically assigned this
values such as when using Array.prototype.map
with a context
argument. Normally, the rule will flag the use of this
whenever a function does not use bind()
to specify the value of this
constantly.
Examples of incorrect code for the { "allowUnboundThis": false }
option:
/*eslint prefer-arrow-callback: ["error", { "allowUnboundThis": false }]*/
/*eslint-env es6*/
foo(function() { this.a; });
foo(function() { (() => this); });
someArray.map(function (itm) { return this.doSomething(itm); }, someObject);
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about function expressions in an argument list, you can safely disable this rule. Source: http://eslint.org/docs/rules/
Unexpected function expression. Open
Object.keys(proxyTable).forEach(function (context) {
- Read upRead up
- Exclude checks
Suggest using arrow functions as callbacks. (prefer-arrow-callback)
Arrow functions are suited to callbacks, because:
-
this
keywords in arrow functions bind to the upper scope's. - The notation of the arrow function is shorter than function expression's.
Rule Details
This rule is aimed to flag usage of function expressions in an argument list.
The following patterns are considered problems:
/*eslint prefer-arrow-callback: "error"*/
foo(function(a) { return a; });
foo(function() { return this.a; }.bind(this));
The following patterns are not considered problems:
/*eslint prefer-arrow-callback: "error"*/
/*eslint-env es6*/
foo(a => a);
foo(function*() { yield; });
// this is not a callback.
var foo = function foo(a) { return a; };
// using `this` without `.bind(this)`.
foo(function() { return this.a; });
// recursively.
foo(function bar(n) { return n && n + bar(n - 1); });
Options
This rule takes one optional argument, an object which is an options object.
allowNamedFunctions
This is a boolean
option and it is false
by default. When set to true
, the rule doesn't warn on named functions used as callbacks.
Examples of correct code for the { "allowNamedFunctions": true }
option:
/*eslint prefer-arrow-callback: ["error", { "allowNamedFunctions": true }]*/
foo(function bar() {});
allowUnboundThis
This is a boolean
option and it is true
by default. When set to false
, this option allows the use of this
without restriction and checks for dynamically assigned this
values such as when using Array.prototype.map
with a context
argument. Normally, the rule will flag the use of this
whenever a function does not use bind()
to specify the value of this
constantly.
Examples of incorrect code for the { "allowUnboundThis": false }
option:
/*eslint prefer-arrow-callback: ["error", { "allowUnboundThis": false }]*/
/*eslint-env es6*/
foo(function() { this.a; });
foo(function() { (() => this); });
someArray.map(function (itm) { return this.doSomething(itm); }, someObject);
When Not To Use It
This rule should not be used in ES3/5 environments.
In ES2015 (ES6) or later, if you don't want to be notified about function expressions in an argument list, you can safely disable this rule. Source: http://eslint.org/docs/rules/
Missing semicolon. Open
})
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option:
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Missing trailing comma. Open
quiet: true
- 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/
Missing trailing comma. Open
log: () => {}
- 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/
Unexpected console statement. Open
console.log('> Listening at ' + uri + '\n')
- Read upRead up
- Exclude checks
disallow the use of console
(no-console)
In JavaScript that is designed to be executed in the browser, it's considered a best practice to avoid using methods on console
. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console
should be stripped before being pushed to production.
console.log("Made it here.");
console.error("That shouldn't have happened.");
Rule Details
This rule disallows calls to methods of the console
object.
Examples of incorrect code for this rule:
/*eslint no-console: "error"*/
console.log("Log a debug level message.");
console.warn("Log a warn level message.");
console.error("Log an error level message.");
Examples of correct code for this rule:
/*eslint no-console: "error"*/
// custom console
Console.log("Hello world!");
Options
This rule has an object option for exceptions:
-
"allow"
has an array of strings which are allowed methods of theconsole
object
Examples of additional correct code for this rule with a sample { "allow": ["warn", "error"] }
option:
/*eslint no-console: ["error", { allow: ["warn", "error"] }] */
console.warn("Log a warn level message.");
console.error("Log an error level message.");
When Not To Use It
If you're using Node.js, however, console
is used to output information to the user and so is not strictly used for debugging purposes. If you are developing for Node.js then you most likely do not want this rule enabled.
Related Rules
- [no-alert](no-alert.md)
- [no-debugger](no-debugger.md) Source: http://eslint.org/docs/rules/
Unexpected console statement. Open
console.log(err)
- Read upRead up
- Exclude checks
disallow the use of console
(no-console)
In JavaScript that is designed to be executed in the browser, it's considered a best practice to avoid using methods on console
. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console
should be stripped before being pushed to production.
console.log("Made it here.");
console.error("That shouldn't have happened.");
Rule Details
This rule disallows calls to methods of the console
object.
Examples of incorrect code for this rule:
/*eslint no-console: "error"*/
console.log("Log a debug level message.");
console.warn("Log a warn level message.");
console.error("Log an error level message.");
Examples of correct code for this rule:
/*eslint no-console: "error"*/
// custom console
Console.log("Hello world!");
Options
This rule has an object option for exceptions:
-
"allow"
has an array of strings which are allowed methods of theconsole
object
Examples of additional correct code for this rule with a sample { "allow": ["warn", "error"] }
option:
/*eslint no-console: ["error", { allow: ["warn", "error"] }] */
console.warn("Log a warn level message.");
console.error("Log an error level message.");
When Not To Use It
If you're using Node.js, however, console
is used to output information to the user and so is not strictly used for debugging purposes. If you are developing for Node.js then you most likely do not want this rule enabled.
Related Rules
- [no-alert](no-alert.md)
- [no-debugger](no-debugger.md) Source: http://eslint.org/docs/rules/
Expected empty line after require statement not followed by another require. Open
var config = require('../config')
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/