Showing 143 of 143 total issues
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/
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';
}
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;
}
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/
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.
No unit allowed for values of 0 Open
border-top: 0px;
- Read upRead up
- Exclude checks
Zero Unit
Rule zero-unit
will enforce whether or not values of 0
used for length should be unitless.
Options
-
include
:true
/false
(defaults tofalse
)
Examples
When include: false
, the following are allowed. When include: true
, the following are disallowed:
.foo {
margin: 0;
}
.bar {
padding: 5px 0 0;
}
When include: true
, the following are allowed. When include: false
, the following are disallowed:
.foo {
margin: 0px;
}
.bar {
padding: 5px 0px 0px;
}
Don't include leading zeros on numbers Open
opacity: 0.8;
- Read upRead up
- Exclude checks
Leading Zero
Rule leading-zero
will enforce whether or not decimal numbers should include a leading zero.
Options
-
include
:true
/false
(defaults tofalse
)
Examples
When include: false
, the following are allowed. When include: true
, the following are disallowed:
.foo {
font-size: .5em;
}
When include: true
, the following are allowed. When include: false
, the following are disallowed:
.foo {
font-size: 0.5em;
}
Headers should be surrounded by blank lines Open
#### Describe the bug
- 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
button, .v-icon {
- 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';
}
Color literals such as '#fff' should only be used in variable declarations Open
border: 2px solid #fff;
- 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
)
)
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.
Expected font-size
, found line-height
Open
line-height: 1.4;
- Read upRead up
- Exclude checks
Property Sort Order
Rule property-sort-order
will enforce the order in which declarations are written.
Options
-
order
:'alphabetical'
,'concentric'
,'recess'
,'smacss'
, or[array of properties]
(defaults toalphabetical
. Unknown properties are sorted alphabetically) -
ignore-custom-properties
:true
/false
(defaults tofalse
)
Property orders: https://github.com/sasstools/sass-lint/tree/develop/lib/config/property-sort-orders
Examples
When enabled (assuming order: alphabetical
), the following are allowed:
.foo {
content: 'baz';
height: 100vh;
width: 100vw;
}
When enabled (assuming order: alphabetical
), the following are disallowed:
.foo {
width: 100vw;
height: 100vh;
content: 'baz';
}
Custom Sort Orders
You have the option to create your own custom property sort orders. These are specified in your .sass-lint.yml
file as below:
property-sort-order:
- 1
-
order:
- border
- display
- color
When the custom order is specified as above, the following are allowed:
.foo {
border: 1px solid blue;
display: block;
color: red;
}
When the custom order is specified as above, the following are disallowed:
.foo {
display: block;
color: red;
border: 1px solid blue;
}
Ignore Custom Properties
When ignore-custom-properties: false
(assume order: 'alphabetical'
) the following would be allowed
.foo {
border: 1px solid blue;
color: red;
composes: heading;
display: block;
}
When ignore-custom-properties: false
(assume order: 'alphabetical'
) the following would be disallowed
.foo {
composes: heading; // not in alphabetical order
border: 1px solid blue;
color: red;
display: block;
}
When ignore-custom-properties: true
(assume order: 'alphabetical'
) the following would be allowed
.foo {
composes: heading; // custom properties ignored
border: 1px solid blue;
color: red;
display: block;
}
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';
}
Selectors must be placed on new lines Open
a, .v-tab {
- 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';
}
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
export { default as emailService } from './emailService';
- Read upRead up
- Exclude checks
For more information visit 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/
Parsing error: 'import' and 'export' may appear only with 'sourceType: module' Open
import 'nprogress/nprogress.css';
- 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 cryptico from 'cryptico-js';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/