Airtame stylelint configuration
Usage
Install as a development dependency to your project
$ yarn add --dev stylelint-config-airtame
or
$ npm install --save-dev stylelint-config-airtame
Then, on your stylelint
configuration file
Rules
block-closing-brace-newline-after
Declare all blocks in a new line
// bad a b a b // good a b
block-closing-brace-newline-before
All blocks must be closed in a new line
// bad a // good a
block-no-empty
No blocks should be declared and be left empty
// bad a
block-opening-brace-newline-after
Rule declarations should be in a new line after the opening curly bracket
// bad a // good a
color-hex-length
When using hex colors, the full hex code should be used to define it
// bad body // good body
color-named
Named colors should never be used.
// bad body // good body p
color-no-invalid-hex
Ensures all hex values used are valid
// bad body
declaration-block-no-shorthand-property-overrides
Do not override a rule with a higher scoped rule. This prevents undesired results
// bad a // good a
declaration-block-semicolon-newline-after
Each rule should appear in a new line. Also, make sure no trailing spaces are left after a semicolon
// bad a p // good a p
declaration-block-trailing-semicolon
All rules should end with a semicolon.
// bad a // good a
declaration-colon-space-before
Never add a space before a rule declaration's colon
// bad body // good body
declaration-colon-space-after
Always leave a space after a declaration's colon
// bad body // good body
declaration-no-important
Never use the !important
tag. This usually means you're not targeting your CSS properly
// VERY BAD a // good - cascade your elements properly .description p a
indentation
Use 2 spaces for indentation
// bad a // good a
max-nesting-depth
When using SCSS, do not nest more than 3 times in depth.
// bad body // good - provide good classes to easily cascade your rules body
max-empty-lines
Do not leave more than 1 empty line between your rules and declarations
// bad a b
number-no-trailing-zeros
Do not add trailing zeros for decimal values either
// bad div // good div
rule-empty-line-before
Always add an empty line before new rules
// bad a b // bad a b // good a b
scss/at-mixin-argumentless-call-parentheses
Always use parenthesis when using a mixin, even if it doesn't take any parameters
Why? Consistency and easier code reading;
// bad div // good div
selector-combinator-space-after
When using combinators to add specificity to your selectors, add a space after each of them.
// bad a>b+c~de // good a > b + c ~ d e
selector-combinator-space-before
Similarly, always add a space before the combinators
// bad a>b+c~de // good a > b + c ~ d e
selector-list-comma-newline-after
When applying the same rule to multiple selectors, write each selector in a separate line for readability purposes.
// bad .my-first-class, .my-second-class // good .my-first-selector,.my-second-selector
selector-no-id
Never use ids to style your elements. Use classes instead and leave ids for markup behavior
// bad #my-selector // good .my-semantinc-class-name
selector-type-case
Use lower case and dashes for your class name selector
// bad .MyClassName // good .my-class-name
string-quotes
When wrapping a value in quotes, use single quotes
// bad div:before // good div:before
value-list-comma-space-after
When writing a list, leave a space after each comma
// bad a // good a