Showing 225 of 225 total issues
Avoid deeply nested control flow statements. Open
if (!_.includes(this.alerts, alert)) {
this.alerts.push(alert);
}
Function downloadGoogleMaps
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
downloadGoogleMaps(cb: Function) {
window['mapsCb'] = cb;
let head = document.getElementsByTagName('head')[0];
let mapsApi = document.createElement('script');
if (ENV.environment === 'dev') {
- Read upRead up
Cognitive Complexity
Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.
A method's cognitive complexity is based on a few simple rules:
- Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
- Code is considered more complex for each "break in the linear flow of the code"
- Code is considered more complex when "flow breaking structures are nested"
Further reading
Function onSearchQueryChanged
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
onSearchQueryChanged(query: string): void {
if (!query || query === '') {
this.routesDisp = this.routes;
this.stopsDisp = this.stops;
this.searchQuery = '';
- Read upRead up
Cognitive Complexity
Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.
A method's cognitive complexity is based on a few simple rules:
- Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
- Code is considered more complex for each "break in the linear flow of the code"
- Code is considered more complex when "flow breaking structures are nested"
Further reading
Do not use comma operator here because it can be easily misunderstood or lead to unintended bugs. Open
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*currdate;a=s.createElement(o),
- Read upRead up
- Exclude checks
Rule: ban-comma-operator
Disallows the comma operator to be used.
Read more about the comma operator here.
Rationale
Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.
Examples
foo((bar, baz)); // evaluates to 'foo(baz)' because of the extra parens - confusing and not obvious
switch (foo) {
case 1, 2: // equals 'case 2' - probably intended 'case 1: case2:'
return true;
case 3:
return false;
}
let x = (y = 1, z = 2); // x is equal to 2 - this may not be immediately obvious.
Examples
"ban-comma-operator": true
For more information see this page.
Identifier 'loader' is never reassigned; use 'const' instead of 'let'. Open
let loader = this.loadingCtrl.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.
Named imports must be alphabetized. Open
import { Component, ViewChild, ElementRef } from '@angular/core';
- 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 'currdate' is never reassigned; use 'const' instead of 'var'. Open
var currdate: any = new Date();
- 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 { FavoriteRouteService, FavoriteRouteModel } from '../../providers/favorite-route.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.
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 { 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.
Identifier 'options' is never reassigned; use 'const' instead of 'let'. Open
let options = {timeout: 5000, enableHighAccuracy: true};
- 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 'neBound' is never reassigned; use 'const' instead of 'let'. Open
let neBound = new google.maps.LatLng(42.51138, -72.20302);
- 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 'loadedTrip' is never reassigned; use 'const' instead of 'let'. Open
let loadedTrip = this.navParams.get('loadedTrip');
- 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 'destinationInput' is never reassigned; use 'const' instead of 'let'. Open
let destinationInput = <HTMLInputElement>document.getElementById('destination-input');
- 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 'transitOptions' is never reassigned; use 'const' instead of 'let'. Open
let transitOptions = {
- 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 'autoRefreshValidity' is never reassigned; use 'const' instead of 'let'. Open
let autoRefreshValidity: [boolean, number] = this.refreshSvc
- 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
for (let alert of alerts) {
- 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 { 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.
Identifier 'isIE' is never reassigned; use 'const' instead of 'let'. Open
let isIE: boolean = navigator.userAgent.indexOf('Trident', 0) !== -1;
- 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.
Forbidden 'var' keyword, use 'let' or 'const' instead Open
export var gaElems: any = {};
- 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.