Showing 225 of 225 total issues
Identifier 'msg' is never reassigned; use 'const' instead of 'var'. Open
var msg = 'Current position found, but no previous position or has moved; calculating stop distances.';
- 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 'mockFaveRouteSvc' is never reassigned; use 'const' instead of 'let'. Open
let mockFaveRouteSvc = fixture.debugElement.injector.get(FavoriteRouteService);
- 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 'mockFaveStopSvc' is never reassigned; use 'const' instead of 'let'. Open
let mockFaveStopSvc = fixture.debugElement.injector.get(FavoriteStopService);
- 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 'routeId' is never reassigned; use 'const' instead of 'let'. Open
for (let routeId of alert.Routes) {
- 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 'routeModal' is never reassigned; use 'const' instead of 'let'. Open
let routeModal = this.modalCtrl.create(RouteModal,
- 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.
Parentheses are required when invoking a constructor Open
this.directionsDisplay = new google.maps.DirectionsRenderer;
- Read upRead up
- Exclude checks
Rule: new-parens
Requires parentheses when invoking a constructor via the new
keyword.
Rationale
Maintains stylistic consistency with other function calls.
Config
Not configurable.
Examples
"new-parens": true
For more information see this page.
Identifier 'destinationAutocomplete' is never reassigned; use 'const' instead of 'let'. Open
let destinationAutocomplete = new google.maps.places.Autocomplete(destinationInput);
- 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
var icon = {
- 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.
asterisks in jsdoc must be aligned Open
*/
- 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.
Forbidden 'var' keyword, use 'let' or 'const' instead Open
var currentPosition = {
- 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.
Identifier 'fr' is never reassigned; use 'const' instead of 'let'. Open
let fr: Promise<any> = this.getfavRoutes();
- 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 'stop' is never reassigned; use 'const' instead of 'let'. Open
for (let stop of this.stops) {
- 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.
Type boolean trivially inferred from a boolean literal, remove type annotation Open
isInternetExplorer: 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.
Named imports must be alphabetized. Open
import { IonicModule, NavParams, 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
export var gaNewElem: 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.
Identifier 'alert' is never reassigned; use 'const' instead of 'let'. Open
for (let alert of downloadedAlerts) {
- 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.
Type boolean trivially inferred from a boolean literal, remove type annotation Open
isInternetExplorer: 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.
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.
Identifier 'currentPosition' is never reassigned; use 'const' instead of 'var'. Open
var currentPosition = {
- 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 { 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.