Showing 143 of 143 total issues
Color literals such as '#777' should only be used in variable declarations Open
color: #777;
- Read upRead up
- Exclude checks
No Color Literals
Rule no-color-literals
will disallow the use of color literals and basic color functions in any declarations other than variables or maps/lists.
The list of affected color functions are as follows:
* rgb
* rgba
* hsl
* hsla
Other color functions, such as adjust-color
and mix
, may be used, but the original color must be passed in as a variable.
Options
-
allow-map-identifiers
:true
/false
(defaults totrue
) -
allow-rgba
:true
/false
(defaults tofalse
) -
allow-variable-identifiers
:true
/false
(defaults totrue
)
Examples
When enabled and default options are used the following are disallowed.
.literal {
color: mediumslateblue;
}
.linear-gradient-func {
background: linear-gradient(top, #fff, white);
}
.box-shadow {
box-shadow: 1px 1px black, 1px 1px black;
}
.background {
background: 1px solid white;
}
.hex {
color: #fff;
}
// rgb function passed directly as function argument
.adj {
color: adjust-color(rgb(255, 0, 0), $blue: 5);
}
// hsl function passed directly as function argument
.scale {
color: scale-color(hsl(120, 70%, 80%), $lightness: 50%);
}
// hsl function passed directly as function argument
.change {
color: change-color(hsl(25, 100%, 80%), $lightness: 40%, $alpha: .8);
}
// color literal passed directly as function argument
.function {
color: test(#fff);
}
// color functions used directly as property values
.rgb {
color: rgb(255, 255, 255);
}
.rgba {
color: rgba(255, 255, 255, .3);
}
.hsl {
color: hsl(40, 50%, 50%);
}
.hsla {
color: hsla(40, 50%, 50%, .3);
}
When enabled and default options are used the following are allowed.
$literal: mediumslateblue;
$hexVar: #fff;
$rgb: rgb(255, 255, 255);
$rgba: rgba(255, 255, 255, .3);
$hsl: hsl(40, 50%, 50%);
$hsla: hsla(40, 50%, 50%, .3);
// using color literals as property names
$colors: (
red: #fff,
blue : (
orange: #fff
)
);
// using color literals as variable identifiers
$black: #000;
.literal {
color: $literal;
}
.linear-gradient-func {
background: linear-gradient(top, $hexVar, $literal);
}
.background {
background: 1px solid $literal;
}
.hex {
color: $hexVar;
}
.adj {
color: adjust-color($off-red, $blue: 5);
}
.scale {
color: scale-color($off-blue, $lightness: 50%);
}
.change {
color: change-color($orange-extra, $lightness: 40%, $alpha: .8);
}
.function {
color: test($hexVar);
}
.rgb {
color: $rgb;
}
.rgba {
color: $rgba;
}
.hsl {
color: $hsl;
}
.hsla {
color: $hsla;
}
[allow-rgba: true]
When enabled and allow-rgba
is set to true
, the following will be allowed:
// rgba in variables is still fine
$rgba: rgba(255, 0, 0, .5);
$red: rgb(255, 255, 255,);
// rgba can be used directly to alter a variables opacity
.color {
color: rgba($red, .3);
}
In addition, when enabled and allow-rgba
is set to true
, the following will be disallowed:
.color {
// you must use variables and not literals
color: rgba(0, 0, 0, .3);
color: rgba(black, .3);
}
[allow-variable-identifiers: false]
When enabled and allow-variable-identifiers
is set to false
, the following will be disallowed
// variable uses a color literal as an identifier
$black: #000
// variable using a color literal as an identifier is passed to a function
.test {
color: adjust-color($off-red, $blue: 5)
}
When enabled and allow-variable-identifiers
is set to false
, the following will be allowed
// variable not directly using a color literal as an identifier
$primary-black: #000
[allow-map-identifiers: false]
When enabled and allow-map-identifiers
is set to false
, the following will be disallowed
// map identifiers red, blue and orange share their name with a
// color literal and therefore shouldn't be used
$colors: (
red: #f00,
blue: (
orange: $orange
)
)
When enabled and allow-map-identifiers
is set to false
, the following will be allowed
$colors: (
primary-red: #f00,
map-blue: (
off-orange: $orange
)
)
Parsing error: 'import' and 'export' may appear only with 'sourceType: module' Open
import { getokAxios } from '@/services/interceptors';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Parsing error: 'import' and 'export' may appear only with 'sourceType: module' Open
import cryptico from 'cryptico-js';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Strings must use singlequote. Open
"vetur.useWorkspaceDependencies": true,
- Read upRead up
- Exclude checks
enforce the consistent use of either backticks, double, or single quotes (quotes)
JavaScript allows you to define strings in one of three ways: double quotes, single quotes, and backticks (as of ECMAScript 6). For example:
/*eslint-env es6*/
var double = "double";
var single = 'single';
var backtick = `backtick`; // ES6 only
Each of these lines creates a string and, in some cases, can be used interchangeably. The choice of how to define strings in a codebase is a stylistic one outside of template literals (which allow embedded of expressions to be interpreted).
Many codebases require strings to be defined in a consistent manner.
Rule Details
This rule enforces the consistent use of either backticks, double, or single quotes.
Options
This rule has two options, a string option and an object option.
String option:
-
"double"
(default) requires the use of double quotes wherever possible -
"single"
requires the use of single quotes wherever possible -
"backtick"
requires the use of backticks wherever possible
Object option:
-
"avoidEscape": true
allows strings to use single-quotes or double-quotes so long as the string contains a quote that would have to be escaped otherwise -
"allowTemplateLiterals": true
allows strings to use backticks
Deprecated: The object property avoid-escape
is deprecated; please use the object property avoidEscape
instead.
double
Examples of incorrect code for this rule with the default "double"
option:
/*eslint quotes: ["error", "double"]*/
var single = 'single';
var unescaped = 'a string containing "double" quotes';
var backtick = `back\ntick`; // you can use \n in single or double quoted strings
Examples of correct code for this rule with the default "double"
option:
/*eslint quotes: ["error", "double"]*/
/*eslint-env es6*/
var double = "double";
var backtick = `back
tick`; // backticks are allowed due to newline
var backtick = tag`backtick`; // backticks are allowed due to tag
single
Examples of incorrect code for this rule with the "single"
option:
/*eslint quotes: ["error", "single"]*/
var double = "double";
var unescaped = "a string containing 'single' quotes";
Examples of correct code for this rule with the "single"
option:
/*eslint quotes: ["error", "single"]*/
/*eslint-env es6*/
var single = 'single';
var backtick = `back${x}tick`; // backticks are allowed due to substitution
backticks
Examples of incorrect code for this rule with the "backtick"
option:
/*eslint quotes: ["error", "backtick"]*/
var single = 'single';
var double = "double";
var unescaped = 'a string containing `backticks`';
Examples of correct code for this rule with the "backtick"
option:
/*eslint quotes: ["error", "backtick"]*/
/*eslint-env es6*/
var backtick = `backtick`;
avoidEscape
Examples of additional correct code for this rule with the "double", { "avoidEscape": true }
options:
/*eslint quotes: ["error", "double", { "avoidEscape": true }]*/
var single = 'a string containing "double" quotes';
Examples of additional correct code for this rule with the "single", { "avoidEscape": true }
options:
/*eslint quotes: ["error", "single", { "avoidEscape": true }]*/
var double = "a string containing 'single' quotes";
Examples of additional correct code for this rule with the "backtick", { "avoidEscape": true }
options:
/*eslint quotes: ["error", "backtick", { "avoidEscape": true }]*/
var double = "a string containing `backtick` quotes"
allowTemplateLiterals
Examples of additional correct code for this rule with the "double", { "allowTemplateLiterals": true }
options:
/*eslint quotes: ["error", "double", { "allowTemplateLiterals": true }]*/
var double = "double";
var double = `double`;
Examples of additional correct code for this rule with the "single", { "allowTemplateLiterals": true }
options:
/*eslint quotes: ["error", "single", { "allowTemplateLiterals": true }]*/
var single = 'single';
var single = `single`;
{ "allowTemplateLiterals": false }
will not disallow the usage of all template literals. If you want to forbid any instance of template literals, use no-restricted-syntax and target the TemplateLiteral
selector.
When Not To Use It
If you do not need consistency in your string styles, you can safely disable this rule. Source: http://eslint.org/docs/rules/
Missing semicolon. Open
}
- Read upRead up
- Exclude checks
require or disallow semicolons instead of ASI (semi)
JavaScript doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:
var name = "ESLint"
var website = "eslint.org";
On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.
In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.
However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:
return
{
name: "ESLint"
};
This may look like a return
statement that returns an object literal, however, the JavaScript engine will interpret this code as:
return;
{
name: "ESLint";
}
Effectively, a semicolon is inserted after the return
statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.
On the other side of the argument are those who say that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:
var globalCounter = { }
(function () {
var n = 0
globalCounter.increment = function () {
return ++n
}
})()
In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.
Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n
character always ends a statement (just like a semicolon) unless one of the following is true:
- The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with
.
or,
.) - The line is
--
or++
(in which case it will decrement/increment the next token.) - It is a
for()
,while()
,do
,if()
, orelse
, and there is no{
- The next line starts with
[
,(
,+
,*
,/
,-
,,
,.
, or some other binary operator that can only be found between two tokens in a single expression.
Rule Details
This rule enforces consistent use of semicolons.
Options
This rule has two options, a string option and an object option.
String option:
-
"always"
(default) requires semicolons at the end of statements -
"never"
disallows semicolons as the end of statements (except to disambiguate statements beginning with[
,(
,/
,+
, or-
)
Object option (when "always"
):
-
"omitLastInOneLineBlock": true
ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line
Object option (when "never"
):
-
"beforeStatementContinuationChars": "any"
(default) ignores semicolons (or lacking semicolon) at the end of statements if the next line starts with[
,(
,/
,+
, or-
. -
"beforeStatementContinuationChars": "always"
requires semicolons at the end of statements if the next line starts with[
,(
,/
,+
, or-
. -
"beforeStatementContinuationChars": "never"
disallows semicolons as the end of statements if it doesn't make ASI hazard even if the next line starts with[
,(
,/
,+
, or-
.
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint semi: ["error", "always"]*/
var name = "ESLint"
object.method = function() {
// ...
}
Examples of correct code for this rule with the default "always"
option:
/*eslint semi: "error"*/
var name = "ESLint";
object.method = function() {
// ...
};
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint";
object.method = function() {
// ...
};
Examples of correct code for this rule with the "never"
option:
/*eslint semi: ["error", "never"]*/
var name = "ESLint"
object.method = function() {
// ...
}
var name = "ESLint"
;(function() {
// ...
})()
import a from "a"
(function() {
// ...
})()
import b from "b"
;(function() {
// ...
})()
omitLastInOneLineBlock
Examples of additional correct code for this rule with the "always", { "omitLastInOneLineBlock": true }
options:
/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */
if (foo) { bar() }
if (foo) { bar(); baz() }
beforeStatementContinuationChars
Examples of additional incorrect code for this rule with the "never", { "beforeStatementContinuationChars": "always" }
options:
/*eslint semi: ["error", "never", { "beforeStatementContinuationChars": "always"}] */
import a from "a"
(function() {
// ...
})()
Examples of additional incorrect code for this rule with the "never", { "beforeStatementContinuationChars": "never" }
options:
/*eslint semi: ["error", "never", { "beforeStatementContinuationChars": "never"}] */
import a from "a"
;(function() {
// ...
})()
When Not To Use It
If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.
Further Reading
Related Rules
- [no-extra-semi](no-extra-semi.md)
- [no-unexpected-multiline](no-unexpected-multiline.md)
- [semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/
Trailing punctuation in header Open
#### Smartphone (please complete the following information):
- Read upRead up
- Exclude checks
MD026 - Trailing punctuation in header
Tags: headers
Aliases: no-trailing-punctuation
Parameters: punctuation (string; default ".,;:!?")
This rule is triggered on any header that has a punctuation character as the last character in the line:
# This is a header.
To fix this, remove any trailing punctuation:
# This is a header
Note: The punctuation parameter can be used to specify what characters class
as punctuation at the end of the header. For example, you can set it to
'.,;:!'
to allow headers with question marks in them, such as might be used
in an FAQ.
Space expected between blocks Open
&:hover {
- Read upRead up
- Exclude checks
Empty Line Between Blocks
Rule empty-line-between-blocks
will enforce whether or not nested blocks should include a space between the last non-comment declaration or not.
Options
-
include
:true
/false
(defaults totrue
) -
allow-single-line-rulesets
:true
/false
(defaults totrue
)
Examples
include
When include: true
, the following are allowed. When include: false
, the following are disallowed:
.foo {
content: 'foo';
.bar {
content: 'bar';
// Waldo
&--baz {
content: 'baz';
}
}
}
When include: false
, the following are allowed. When include: true
, the following are disallowed:
.foo {
content: 'foo';
.bar {
content: 'bar';
// Waldo
&--baz {
content: 'baz';
}
}
}
allow-single-line-rulesets
When allow-single-line-rulesets: true
, the following are allowed. When allow-single-line-rulesets: false
, the following are disallowed:
.foo { content: 'foo'; }
.bar { content: 'bar'; }
.baz { content: 'baz'; }
Parsing error: 'import' and 'export' may appear only with 'sourceType: module' Open
import Keycloak from 'keycloak-js';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Headers should be surrounded by blank lines Open
#### Additional context
- Read upRead up
- Exclude checks
MD022 - Headers should be surrounded by blank lines
Tags: headers, blank_lines
Aliases: blanks-around-headers
This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:
# Header 1
Some text
Some more text
## Header 2
To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):
# Header 1
Some text
Some more text
## Header 2
Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.
Parsing error: 'import' and 'export' may appear only with 'sourceType: module' Open
import Vue from 'vue';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Parsing error: 'import' and 'export' may appear only with 'sourceType: module' Open
import { getokAxios } from '@/services/interceptors';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Parsing error: 'import' and 'export' may appear only with 'sourceType: module' Open
import UserService from '@/services/userService';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Headers should be surrounded by blank lines Open
#### Describe alternatives you've considered
- Read upRead up
- Exclude checks
MD022 - Headers should be surrounded by blank lines
Tags: headers, blank_lines
Aliases: blanks-around-headers
This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:
# Header 1
Some text
Some more text
## Header 2
To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):
# Header 1
Some text
Some more text
## Header 2
Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.
Selectors must be placed on new lines Open
h1, h2, h3, h4, h5 {
- Read upRead up
- Exclude checks
Single Line Per Selector
Rule single-line-per-selector
will enforce whether selectors should be placed on a new line.
Examples
When enabled, the following are allowed:
.foo,
.bar {
content: 'baz';
}
When enabled, the following are disallowed:
.foo, .bar {
content: 'baz';
}
Parsing error: 'import' and 'export' may appear only with 'sourceType: module' Open
import Vue from 'vue';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
File extensions are not allowed Open
@import '~vuetify/src/styles/styles.sass';
- Read upRead up
- Exclude checks
Clean Import Paths
Rule clean-import-paths
will enforce whether or not @import
paths should have leading underscores and/or filename extensions.
Options
-
leading-underscore
:true
/false
(defaults tofalse
) -
filename-extension
:true
/false
(defaults tofalse
)
Examples
leading-underscore
When leading-underscore: false
, the following are allowed. When leading-underscore: true
, the following are disallowed:
@import 'foo';
@import 'bar/foo';
When leading-underscore: true
, the following are allowed. When leading-underscore: false
, the following are disallowed:
@import '_foo';
@import '_bar/foo';
filename-extension
When filename-extension: false
, the following are allowed. When filename-extension: true
, the following are disallowed:
@import 'foo';
@import 'bar/foo';
When filename-extension: true
, the following are allowed. When filename-extension: false
, the following are disallowed:
@import 'foo.scss';
@import 'bar/foo.scss';
!important not allowed Open
font-family: -apple-system, BlinkMacSystemFont, BCSans, Roboto, Verdana, Arial, sans-serif !important;
- Read upRead up
- Exclude checks
No Important
Rule no-important
will enforce that important declarations are not allowed to be used.
Examples
When enabled, the following are disallowed:
.foo {
content: 'bar' !important;
}
Color 'lightgray' should be written in its hexadecimal form #d3d3d3 Open
color: lightgray;
- Read upRead up
- Exclude checks
Color Keyword
Rule no-color-keywords
will enforce the use of hexadecimal color values rather than literals.
Examples
When enabled the following are allowed:
$new-red: #ff0000;
.foo {
color: #ff0000;
}
When enabled the following are disallowed:
$new-red: red;
.foo {
color: red;
}
Trailing punctuation in header Open
#### Desktop (please complete the following information):
- Read upRead up
- Exclude checks
MD026 - Trailing punctuation in header
Tags: headers
Aliases: no-trailing-punctuation
Parameters: punctuation (string; default ".,;:!?")
This rule is triggered on any header that has a punctuation character as the last character in the line:
# This is a header.
To fix this, remove any trailing punctuation:
# This is a header
Note: The punctuation parameter can be used to specify what characters class
as punctuation at the end of the header. For example, you can set it to
'.,;:!'
to allow headers with question marks in them, such as might be used
in an FAQ.
Hex values should use the shorthand format - 3 characters where possible Open
border: 2px solid #003366;
- Read upRead up
- Exclude checks
Hex Length
Rule hex-length
will enforce the length of hexadecimal values
Options
-
style
:short
/long
(defaults toshort
)
Examples
When style: short
, the following are allowed. When style: long
, the following are disallowed:
$foo-color: #456;
.bar {
background: linear-gradient(top, #3ff, #ddd);
}
.baz {
color: #fff;
}
When style: long
, the following are allowed. When style: short
, the following are disallowed:
$foo-color: #445566;
.bar {
background: linear-gradient(top, #33ffff, #dddddd);
}
.baz {
color: #ffffff;
}
In both cases the following will be allowed as the values cannot be shortened:
$quz-color: #abcdef;
.qux {
color: #123456;
}