Showing 225 of 225 total issues
Type boolean trivially inferred from a boolean literal, remove type annotation Open
directionsRequested: boolean = false;
- Read upRead up
- Exclude checks
Rule: no-inferrable-types
Disallows explicit type declarations for variables or parameters initialized to a number, string, or boolean.
Rationale
Explicit types where they can be easily inferred by the compiler make code more verbose.
Notes
- TypeScript Only
- Has Fix
Config
Two arguments may be optionally provided:
-
ignore-params
allows specifying an inferrable type annotation for function params. This can be useful when combining with thetypedef
rule. -
ignore-properties
allows specifying an inferrable type annotation for class properties.
Examples
"no-inferrable-types": true
"no-inferrable-types": true,ignore-params
"no-inferrable-types": true,ignore-params,ignore-properties
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"ignore-params",
"ignore-properties"
]
},
"minLength": 0,
"maxLength": 2
}
For more information see this page.
Forbidden 'var' keyword, use 'let' or 'const' instead Open
var currdate: any = new Date();
- Read upRead up
- Exclude checks
Rule: no-var-keyword
Disallows usage of the var
keyword.
Use let
or const
instead.
Rationale
Declaring variables using var
has several edge case behaviors that make var
unsuitable for modern code.
Variables declared by var
have their parent function block as their scope, ignoring other control flow statements.
var
s have declaration "hoisting" (similar to function
s) and can appear to be used before declaration.
Variables declared by const
and let
instead have as their scope the block in which they are defined,
and are not allowed to used before declaration or be re-declared with another const
or let
.
Notes
- Has Fix
Config
Not configurable.
Examples
"no-var-keyword": true
For more information see this page.
Named imports must be alphabetized. Open
import { FavoriteStopService, FavoriteStopModel } from '../../providers/favorite-stop.service';
- Read upRead up
- Exclude checks
Rule: ordered-imports
Requires that import statements be alphabetized and grouped.
Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.
Notes
- Has Fix
Config
You may set the "import-sources-order"
option to control the ordering of source
imports (the "foo"
in import {A, B, C} from "foo"
).
Possible values for "import-sources-order"
are:
-
"case-insensitive'
: Correct order is"Bar"
,"baz"
,"Foo"
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is"baz"
,"Bar"
,"Foo"
. -
"lowercase-last"
: Correct order is"Bar"
,"Foo"
,"baz"
. -
"any"
: Allow any order.
You may set the "grouped-imports"
option to control the grouping of source
imports (the "foo"
in import {A, B, C} from "foo"
). The grouping used
is controlled by the "groups"
option.
Possible values for "grouped-imports"
are:
-
false
: Do not enforce grouping. (This is the default.) -
true
: Group source imports using default grouping or groups setting.
The value of "groups"
is a list of group rules of the form:
[{
"name": "optional rule name",
"match": "regex string",
"order": 10
}, {
"name": "pkga imports",
"match": "^@pkga",
"order": 20
}]
there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list
["^@pkga", "^\.\."]
The first rule in the list to match a given import is the group that is used.
If no rule in matched then the import will be put in an unmatched
group
at the end of all groups. The groups must be ordered based upon the sequential
value of the order
value. (ie. order 0 is first)
If no "groups"
options is set, a default grouping is used of third-party,
parent directories and the current directory. ("bar"
, "../baz"
, "./foo"
.)
You may set the "named-imports-order"
option to control the ordering of named
imports (the {A, B, C}
in import {A, B, C} from "foo"
).
Possible values for "named-imports-order"
are:
-
"case-insensitive'
: Correct order is{A, b, C}
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is{b, A, C}
. -
"lowercase-last"
: Correct order is{A, C, b}
. -
"any"
: Allow any order.
You may set the "module-source-path"
option to control the ordering of imports based full path
or just the module name
Possible values for "module-source-path"
are:
-
"full'
: Correct order is"./a/Foo"
,"./b/baz"
,"./c/Bar"
. (This is the default.) -
"basename"
: Correct order is"./c/Bar"
,"./b/baz"
,"./a/Foo"
.
Examples
"ordered-imports": true
"ordered-imports": true,[object Object]
Schema
{
"type": "object",
"properties": {
"grouped-imports": {
"type": "boolean"
},
"groups": {
"type": "list",
"listType": {
"oneOf": [
{
"type": "string"
},
{
"type": "object",
"properties": {
"name": {
"type": "string"
},
"match": {
"type": "string"
},
"order": {
"type": "number"
}
},
"required": [
"match",
"order"
]
}
]
}
},
"import-sources-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"named-imports-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"module-source-path": {
"type": "string",
"enum": [
"full",
"basename"
]
}
},
"additionalProperties": false
}
For more information see this page.
" should be ' Open
it("calls the FavoriteStopService's remove() function", () => {
- Read upRead up
- Exclude checks
Rule: quotemark
Enforces quote character for string literals.
Notes
- Has Fix
Config
Five arguments may be optionally provided:
-
"single"
enforces single quotes. -
"double"
enforces double quotes. -
"backtick"
enforces backticks. -
"jsx-single"
enforces single quotes for JSX attributes. -
"jsx-double"
enforces double quotes for JSX attributes. -
"avoid-template"
forbids single-line untagged template strings that do not contain string interpolations. Note that backticks may still be used if"avoid-escape"
is enabled and both single and double quotes are present in the string (the latter option takes precedence). -
"avoid-escape"
allows you to use the "other" quotemark in cases where escaping would normally be required. For example,[true, "double", "avoid-escape"]
would not report a failure on the string literal'Hello "World"'
.
Examples
"quotemark": true,single,avoid-escape,avoid-template
"quotemark": true,single,jsx-double
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"single",
"double",
"backtick",
"jsx-single",
"jsx-double",
"avoid-escape",
"avoid-template"
]
},
"minLength": 0,
"maxLength": 5
}
For more information see this page.
asterisks in jsdoc must be aligned Open
* for origin so the user knows to type something.
- Read upRead up
- Exclude checks
Rule: jsdoc-format
Enforces basic format rules for JSDoc comments.
The following rules are enforced for JSDoc comments (comments starting with /**
):
- each line contains an asterisk and asterisks must be aligned
- each asterisk must be followed by either a space or a newline (except for the first and the last)
- the only characters before the asterisk on each line must be whitespace characters
- one line comments must start with
/**
and end with*/
- multiline comments don't allow text after
/**
in the first line (with option"check-multiline-start"
)
Rationale
Helps maintain a consistent, readable style for JSDoc comments.
Config
You can optionally specify the option "check-multiline-start"
to enforce the first line of a
multiline JSDoc comment to be empty.
Examples
"jsdoc-format": true
"jsdoc-format": true,check-multiline-start
Schema
{
"type": "array",
"minItems": 0,
"maxItems": 1,
"items": {
"type": "string",
"enum": [
"check-multiline-start"
]
}
}
For more information see this page.
Identifier 'closestGeolocationAddress' is never reassigned; use 'const' instead of 'let'. Open
let closestGeolocationAddress = results[0];
- Read upRead up
- Exclude checks
Rule: prefer-const
Requires that variable declarations use const
instead of let
and var
if possible.
If a variable is only assigned to once when it is declared, it should be declared using 'const'
Notes
- Has Fix
Config
An optional object containing the property "destructuring" with two possible values:
- "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
- "all" - Only warns if all variables in destructuring can be const.
Examples
"prefer-const": true
"prefer-const": true,[object Object]
Schema
{
"type": "object",
"properties": {
"destructuring": {
"type": "string",
"enum": [
"all",
"any"
]
}
}
}
For more information see this page.
Named imports must be alphabetized. Open
import { IonicApp, IonicModule, IonicErrorHandler } from 'ionic-angular';
- Read upRead up
- Exclude checks
Rule: ordered-imports
Requires that import statements be alphabetized and grouped.
Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.
Notes
- Has Fix
Config
You may set the "import-sources-order"
option to control the ordering of source
imports (the "foo"
in import {A, B, C} from "foo"
).
Possible values for "import-sources-order"
are:
-
"case-insensitive'
: Correct order is"Bar"
,"baz"
,"Foo"
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is"baz"
,"Bar"
,"Foo"
. -
"lowercase-last"
: Correct order is"Bar"
,"Foo"
,"baz"
. -
"any"
: Allow any order.
You may set the "grouped-imports"
option to control the grouping of source
imports (the "foo"
in import {A, B, C} from "foo"
). The grouping used
is controlled by the "groups"
option.
Possible values for "grouped-imports"
are:
-
false
: Do not enforce grouping. (This is the default.) -
true
: Group source imports using default grouping or groups setting.
The value of "groups"
is a list of group rules of the form:
[{
"name": "optional rule name",
"match": "regex string",
"order": 10
}, {
"name": "pkga imports",
"match": "^@pkga",
"order": 20
}]
there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list
["^@pkga", "^\.\."]
The first rule in the list to match a given import is the group that is used.
If no rule in matched then the import will be put in an unmatched
group
at the end of all groups. The groups must be ordered based upon the sequential
value of the order
value. (ie. order 0 is first)
If no "groups"
options is set, a default grouping is used of third-party,
parent directories and the current directory. ("bar"
, "../baz"
, "./foo"
.)
You may set the "named-imports-order"
option to control the ordering of named
imports (the {A, B, C}
in import {A, B, C} from "foo"
).
Possible values for "named-imports-order"
are:
-
"case-insensitive'
: Correct order is{A, b, C}
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is{b, A, C}
. -
"lowercase-last"
: Correct order is{A, C, b}
. -
"any"
: Allow any order.
You may set the "module-source-path"
option to control the ordering of imports based full path
or just the module name
Possible values for "module-source-path"
are:
-
"full'
: Correct order is"./a/Foo"
,"./b/baz"
,"./c/Bar"
. (This is the default.) -
"basename"
: Correct order is"./c/Bar"
,"./b/baz"
,"./a/Foo"
.
Examples
"ordered-imports": true
"ordered-imports": true,[object Object]
Schema
{
"type": "object",
"properties": {
"grouped-imports": {
"type": "boolean"
},
"groups": {
"type": "list",
"listType": {
"oneOf": [
{
"type": "string"
},
{
"type": "object",
"properties": {
"name": {
"type": "string"
},
"match": {
"type": "string"
},
"order": {
"type": "number"
}
},
"required": [
"match",
"order"
]
}
]
}
},
"import-sources-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"named-imports-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"module-source-path": {
"type": "string",
"enum": [
"full",
"basename"
]
}
},
"additionalProperties": false
}
For more information see this page.
Named imports must be alphabetized. Open
import { IonicModule, NavController, ModalController, AlertController } from 'ionic-angular';
- Read upRead up
- Exclude checks
Rule: ordered-imports
Requires that import statements be alphabetized and grouped.
Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.
Notes
- Has Fix
Config
You may set the "import-sources-order"
option to control the ordering of source
imports (the "foo"
in import {A, B, C} from "foo"
).
Possible values for "import-sources-order"
are:
-
"case-insensitive'
: Correct order is"Bar"
,"baz"
,"Foo"
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is"baz"
,"Bar"
,"Foo"
. -
"lowercase-last"
: Correct order is"Bar"
,"Foo"
,"baz"
. -
"any"
: Allow any order.
You may set the "grouped-imports"
option to control the grouping of source
imports (the "foo"
in import {A, B, C} from "foo"
). The grouping used
is controlled by the "groups"
option.
Possible values for "grouped-imports"
are:
-
false
: Do not enforce grouping. (This is the default.) -
true
: Group source imports using default grouping or groups setting.
The value of "groups"
is a list of group rules of the form:
[{
"name": "optional rule name",
"match": "regex string",
"order": 10
}, {
"name": "pkga imports",
"match": "^@pkga",
"order": 20
}]
there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list
["^@pkga", "^\.\."]
The first rule in the list to match a given import is the group that is used.
If no rule in matched then the import will be put in an unmatched
group
at the end of all groups. The groups must be ordered based upon the sequential
value of the order
value. (ie. order 0 is first)
If no "groups"
options is set, a default grouping is used of third-party,
parent directories and the current directory. ("bar"
, "../baz"
, "./foo"
.)
You may set the "named-imports-order"
option to control the ordering of named
imports (the {A, B, C}
in import {A, B, C} from "foo"
).
Possible values for "named-imports-order"
are:
-
"case-insensitive'
: Correct order is{A, b, C}
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is{b, A, C}
. -
"lowercase-last"
: Correct order is{A, C, b}
. -
"any"
: Allow any order.
You may set the "module-source-path"
option to control the ordering of imports based full path
or just the module name
Possible values for "module-source-path"
are:
-
"full'
: Correct order is"./a/Foo"
,"./b/baz"
,"./c/Bar"
. (This is the default.) -
"basename"
: Correct order is"./c/Bar"
,"./b/baz"
,"./a/Foo"
.
Examples
"ordered-imports": true
"ordered-imports": true,[object Object]
Schema
{
"type": "object",
"properties": {
"grouped-imports": {
"type": "boolean"
},
"groups": {
"type": "list",
"listType": {
"oneOf": [
{
"type": "string"
},
{
"type": "object",
"properties": {
"name": {
"type": "string"
},
"match": {
"type": "string"
},
"order": {
"type": "number"
}
},
"required": [
"match",
"order"
]
}
]
}
},
"import-sources-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"named-imports-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"module-source-path": {
"type": "string",
"enum": [
"full",
"basename"
]
}
},
"additionalProperties": false
}
For more information see this page.
Named imports must be alphabetized. Open
import { async, TestBed } from '@angular/core/testing';
- Read upRead up
- Exclude checks
Rule: ordered-imports
Requires that import statements be alphabetized and grouped.
Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.
Notes
- Has Fix
Config
You may set the "import-sources-order"
option to control the ordering of source
imports (the "foo"
in import {A, B, C} from "foo"
).
Possible values for "import-sources-order"
are:
-
"case-insensitive'
: Correct order is"Bar"
,"baz"
,"Foo"
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is"baz"
,"Bar"
,"Foo"
. -
"lowercase-last"
: Correct order is"Bar"
,"Foo"
,"baz"
. -
"any"
: Allow any order.
You may set the "grouped-imports"
option to control the grouping of source
imports (the "foo"
in import {A, B, C} from "foo"
). The grouping used
is controlled by the "groups"
option.
Possible values for "grouped-imports"
are:
-
false
: Do not enforce grouping. (This is the default.) -
true
: Group source imports using default grouping or groups setting.
The value of "groups"
is a list of group rules of the form:
[{
"name": "optional rule name",
"match": "regex string",
"order": 10
}, {
"name": "pkga imports",
"match": "^@pkga",
"order": 20
}]
there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list
["^@pkga", "^\.\."]
The first rule in the list to match a given import is the group that is used.
If no rule in matched then the import will be put in an unmatched
group
at the end of all groups. The groups must be ordered based upon the sequential
value of the order
value. (ie. order 0 is first)
If no "groups"
options is set, a default grouping is used of third-party,
parent directories and the current directory. ("bar"
, "../baz"
, "./foo"
.)
You may set the "named-imports-order"
option to control the ordering of named
imports (the {A, B, C}
in import {A, B, C} from "foo"
).
Possible values for "named-imports-order"
are:
-
"case-insensitive'
: Correct order is{A, b, C}
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is{b, A, C}
. -
"lowercase-last"
: Correct order is{A, C, b}
. -
"any"
: Allow any order.
You may set the "module-source-path"
option to control the ordering of imports based full path
or just the module name
Possible values for "module-source-path"
are:
-
"full'
: Correct order is"./a/Foo"
,"./b/baz"
,"./c/Bar"
. (This is the default.) -
"basename"
: Correct order is"./c/Bar"
,"./b/baz"
,"./a/Foo"
.
Examples
"ordered-imports": true
"ordered-imports": true,[object Object]
Schema
{
"type": "object",
"properties": {
"grouped-imports": {
"type": "boolean"
},
"groups": {
"type": "list",
"listType": {
"oneOf": [
{
"type": "string"
},
{
"type": "object",
"properties": {
"name": {
"type": "string"
},
"match": {
"type": "string"
},
"order": {
"type": "number"
}
},
"required": [
"match",
"order"
]
}
]
}
},
"import-sources-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"named-imports-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"module-source-path": {
"type": "string",
"enum": [
"full",
"basename"
]
}
},
"additionalProperties": false
}
For more information see this page.
Named imports must be alphabetized. Open
import { NavController, NavParams, ModalController, AlertController } from 'ionic-angular';
- Read upRead up
- Exclude checks
Rule: ordered-imports
Requires that import statements be alphabetized and grouped.
Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.
Notes
- Has Fix
Config
You may set the "import-sources-order"
option to control the ordering of source
imports (the "foo"
in import {A, B, C} from "foo"
).
Possible values for "import-sources-order"
are:
-
"case-insensitive'
: Correct order is"Bar"
,"baz"
,"Foo"
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is"baz"
,"Bar"
,"Foo"
. -
"lowercase-last"
: Correct order is"Bar"
,"Foo"
,"baz"
. -
"any"
: Allow any order.
You may set the "grouped-imports"
option to control the grouping of source
imports (the "foo"
in import {A, B, C} from "foo"
). The grouping used
is controlled by the "groups"
option.
Possible values for "grouped-imports"
are:
-
false
: Do not enforce grouping. (This is the default.) -
true
: Group source imports using default grouping or groups setting.
The value of "groups"
is a list of group rules of the form:
[{
"name": "optional rule name",
"match": "regex string",
"order": 10
}, {
"name": "pkga imports",
"match": "^@pkga",
"order": 20
}]
there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list
["^@pkga", "^\.\."]
The first rule in the list to match a given import is the group that is used.
If no rule in matched then the import will be put in an unmatched
group
at the end of all groups. The groups must be ordered based upon the sequential
value of the order
value. (ie. order 0 is first)
If no "groups"
options is set, a default grouping is used of third-party,
parent directories and the current directory. ("bar"
, "../baz"
, "./foo"
.)
You may set the "named-imports-order"
option to control the ordering of named
imports (the {A, B, C}
in import {A, B, C} from "foo"
).
Possible values for "named-imports-order"
are:
-
"case-insensitive'
: Correct order is{A, b, C}
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is{b, A, C}
. -
"lowercase-last"
: Correct order is{A, C, b}
. -
"any"
: Allow any order.
You may set the "module-source-path"
option to control the ordering of imports based full path
or just the module name
Possible values for "module-source-path"
are:
-
"full'
: Correct order is"./a/Foo"
,"./b/baz"
,"./c/Bar"
. (This is the default.) -
"basename"
: Correct order is"./c/Bar"
,"./b/baz"
,"./a/Foo"
.
Examples
"ordered-imports": true
"ordered-imports": true,[object Object]
Schema
{
"type": "object",
"properties": {
"grouped-imports": {
"type": "boolean"
},
"groups": {
"type": "list",
"listType": {
"oneOf": [
{
"type": "string"
},
{
"type": "object",
"properties": {
"name": {
"type": "string"
},
"match": {
"type": "string"
},
"order": {
"type": "number"
}
},
"required": [
"match",
"order"
]
}
]
}
},
"import-sources-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"named-imports-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"module-source-path": {
"type": "string",
"enum": [
"full",
"basename"
]
}
},
"additionalProperties": false
}
For more information see this page.
Identifier 'newStop' is never reassigned; use 'const' instead of 'var'. Open
var newStop = {
- Read upRead up
- Exclude checks
Rule: prefer-const
Requires that variable declarations use const
instead of let
and var
if possible.
If a variable is only assigned to once when it is declared, it should be declared using 'const'
Notes
- Has Fix
Config
An optional object containing the property "destructuring" with two possible values:
- "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
- "all" - Only warns if all variables in destructuring can be const.
Examples
"prefer-const": true
"prefer-const": true,[object Object]
Schema
{
"type": "object",
"properties": {
"destructuring": {
"type": "string",
"enum": [
"all",
"any"
]
}
}
}
For more information see this page.
Identifier 'txt' is never reassigned; use 'const' instead of 'let'. Open
let txt = text;
- Read upRead up
- Exclude checks
Rule: prefer-const
Requires that variable declarations use const
instead of let
and var
if possible.
If a variable is only assigned to once when it is declared, it should be declared using 'const'
Notes
- Has Fix
Config
An optional object containing the property "destructuring" with two possible values:
- "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
- "all" - Only warns if all variables in destructuring can be const.
Examples
"prefer-const": true
"prefer-const": true,[object Object]
Schema
{
"type": "object",
"properties": {
"destructuring": {
"type": "string",
"enum": [
"all",
"any"
]
}
}
}
For more information see this page.
Use a conditional expression instead of assigning to 'this.shownRoute' in multiple places. Open
if (this.isRouteDropdownShown(routeDirection)) {
- Read upRead up
- Exclude checks
Rule: prefer-conditional-expression
Recommends to use a conditional expression instead of assigning to the same thing in each branch of an if statement.
Rationale
This reduces duplication and can eliminate an unnecessary variable declaration.
Config
If check-else-if
is specified, the rule also checks nested if-else-if statements.
Examples
"prefer-conditional-expression": true
"prefer-conditional-expression": true,check-else-if
Schema
{
"type": "string",
"enum": [
"check-else-if"
]
}
For more information see this page.
Identifier 'route' is never reassigned; use 'const' instead of 'let'. Open
let route = this.routeList[departure.RouteId];
- Read upRead up
- Exclude checks
Rule: prefer-const
Requires that variable declarations use const
instead of let
and var
if possible.
If a variable is only assigned to once when it is declared, it should be declared using 'const'
Notes
- Has Fix
Config
An optional object containing the property "destructuring" with two possible values:
- "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
- "all" - Only warns if all variables in destructuring can be const.
Examples
"prefer-const": true
"prefer-const": true,[object Object]
Schema
{
"type": "object",
"properties": {
"destructuring": {
"type": "string",
"enum": [
"all",
"any"
]
}
}
}
For more information see this page.
Identifier 'route' is never reassigned; use 'const' instead of 'let'. Open
for (let route of directions[0].RouteDirections) {
- Read upRead up
- Exclude checks
Rule: prefer-const
Requires that variable declarations use const
instead of let
and var
if possible.
If a variable is only assigned to once when it is declared, it should be declared using 'const'
Notes
- Has Fix
Config
An optional object containing the property "destructuring" with two possible values:
- "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
- "all" - Only warns if all variables in destructuring can be const.
Examples
"prefer-const": true
"prefer-const": true,[object Object]
Schema
{
"type": "object",
"properties": {
"destructuring": {
"type": "string",
"enum": [
"all",
"any"
]
}
}
}
For more information see this page.
Identifier 'alert' is never reassigned; use 'const' instead of 'let'. Open
let alert = this.alertCtrl.create({
- Read upRead up
- Exclude checks
Rule: prefer-const
Requires that variable declarations use const
instead of let
and var
if possible.
If a variable is only assigned to once when it is declared, it should be declared using 'const'
Notes
- Has Fix
Config
An optional object containing the property "destructuring" with two possible values:
- "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
- "all" - Only warns if all variables in destructuring can be const.
Examples
"prefer-const": true
"prefer-const": true,[object Object]
Schema
{
"type": "object",
"properties": {
"destructuring": {
"type": "string",
"enum": [
"all",
"any"
]
}
}
}
For more information see this page.
import with explicit side-effect Open
import 'rxjs/add/operator/toPromise';
- Read upRead up
- Exclude checks
Rule: no-import-side-effect
Avoid import statements with side-effect.
Rationale
Imports with side effects may have behavior which is hard for static verification.
Config
One argument may be optionally provided:
-
ignore-module
allows to specify a regex and ignore modules which it matches.
Examples
"no-import-side-effect": true
"no-import-side-effect": true,[object Object]
Schema
{
"items": {
"properties": {
"ignore-module": {
"type": "string"
}
},
"type": "object"
},
"maxLength": 1,
"minLength": 0,
"type": "array"
}
For more information see this page.
Identifier 'diff' is never reassigned; use 'const' instead of 'let'. Open
let diff = now.diff(stops.time, 'days');
- Read upRead up
- Exclude checks
Rule: prefer-const
Requires that variable declarations use const
instead of let
and var
if possible.
If a variable is only assigned to once when it is declared, it should be declared using 'const'
Notes
- Has Fix
Config
An optional object containing the property "destructuring" with two possible values:
- "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
- "all" - Only warns if all variables in destructuring can be const.
Examples
"prefer-const": true
"prefer-const": true,[object Object]
Schema
{
"type": "object",
"properties": {
"destructuring": {
"type": "string",
"enum": [
"all",
"any"
]
}
}
}
For more information see this page.
Named imports must be alphabetized. Open
import { IonicModule, NavController, NavParams, AlertController, LoadingController } from 'ionic-angular';
- Read upRead up
- Exclude checks
Rule: ordered-imports
Requires that import statements be alphabetized and grouped.
Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.
Notes
- Has Fix
Config
You may set the "import-sources-order"
option to control the ordering of source
imports (the "foo"
in import {A, B, C} from "foo"
).
Possible values for "import-sources-order"
are:
-
"case-insensitive'
: Correct order is"Bar"
,"baz"
,"Foo"
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is"baz"
,"Bar"
,"Foo"
. -
"lowercase-last"
: Correct order is"Bar"
,"Foo"
,"baz"
. -
"any"
: Allow any order.
You may set the "grouped-imports"
option to control the grouping of source
imports (the "foo"
in import {A, B, C} from "foo"
). The grouping used
is controlled by the "groups"
option.
Possible values for "grouped-imports"
are:
-
false
: Do not enforce grouping. (This is the default.) -
true
: Group source imports using default grouping or groups setting.
The value of "groups"
is a list of group rules of the form:
[{
"name": "optional rule name",
"match": "regex string",
"order": 10
}, {
"name": "pkga imports",
"match": "^@pkga",
"order": 20
}]
there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list
["^@pkga", "^\.\."]
The first rule in the list to match a given import is the group that is used.
If no rule in matched then the import will be put in an unmatched
group
at the end of all groups. The groups must be ordered based upon the sequential
value of the order
value. (ie. order 0 is first)
If no "groups"
options is set, a default grouping is used of third-party,
parent directories and the current directory. ("bar"
, "../baz"
, "./foo"
.)
You may set the "named-imports-order"
option to control the ordering of named
imports (the {A, B, C}
in import {A, B, C} from "foo"
).
Possible values for "named-imports-order"
are:
-
"case-insensitive'
: Correct order is{A, b, C}
. (This is the default.) -
"case-insensitive-legacy'
: Correct order is"Bar"
,"baz"
,"Foo"
. -
"lowercase-first"
: Correct order is{b, A, C}
. -
"lowercase-last"
: Correct order is{A, C, b}
. -
"any"
: Allow any order.
You may set the "module-source-path"
option to control the ordering of imports based full path
or just the module name
Possible values for "module-source-path"
are:
-
"full'
: Correct order is"./a/Foo"
,"./b/baz"
,"./c/Bar"
. (This is the default.) -
"basename"
: Correct order is"./c/Bar"
,"./b/baz"
,"./a/Foo"
.
Examples
"ordered-imports": true
"ordered-imports": true,[object Object]
Schema
{
"type": "object",
"properties": {
"grouped-imports": {
"type": "boolean"
},
"groups": {
"type": "list",
"listType": {
"oneOf": [
{
"type": "string"
},
{
"type": "object",
"properties": {
"name": {
"type": "string"
},
"match": {
"type": "string"
},
"order": {
"type": "number"
}
},
"required": [
"match",
"order"
]
}
]
}
},
"import-sources-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"named-imports-order": {
"type": "string",
"enum": [
"case-insensitive",
"case-insensitive-legacy",
"lowercase-first",
"lowercase-last",
"any"
]
},
"module-source-path": {
"type": "string",
"enum": [
"full",
"basename"
]
}
},
"additionalProperties": false
}
For more information see this page.
Forbidden 'var' keyword, use 'let' or 'const' instead Open
var request = {
- Read upRead up
- Exclude checks
Rule: no-var-keyword
Disallows usage of the var
keyword.
Use let
or const
instead.
Rationale
Declaring variables using var
has several edge case behaviors that make var
unsuitable for modern code.
Variables declared by var
have their parent function block as their scope, ignoring other control flow statements.
var
s have declaration "hoisting" (similar to function
s) and can appear to be used before declaration.
Variables declared by const
and let
instead have as their scope the block in which they are defined,
and are not allowed to used before declaration or be re-declared with another const
or let
.
Notes
- Has Fix
Config
Not configurable.
Examples
"no-var-keyword": true
For more information see this page.