The linter supports current and future CSS syntax. This includes all standard CSS but also special features that use standard CSS syntactic structures, e.g. special at-rules, special properties, and special functions. Some CSS-like language extensions -- features that use non-standard syntactic structures -- are, as such, supported; however, since there are infinite processing possibilities, the linter cannot support everything.
You can run the linter before or after your css processors. Depending on which processors you use, each approach has caveats:
- Before: Some plugins/processors might enable a syntax that isn't compatible with the linter.
- After: Some plugins/processors might generate CSS that is invalid against your linter config, causing warnings that do not correspond to your original stylesheets.
In both cases you can either turn off the incompatible linter rule, or stop using the incompatible plugin/processor. You could also approach plugin/processor authors and request alternate formatting options that will make their plugin/processor compatible with stylelint.
The linter can parse any the following non-standard syntaxes by using special PostCSS parsers:
- SCSS (using
postcss-scss
) - Less (using
postcss-less
) - SugarSS (using
sugarss
)
(Whenever someone writes a PostCSS parser for another syntax, stylelint can easily add support for that.)
Both the CLI and the Node API expose a syntax
option.
- If you're using the CLI, use the
syntax
flag like so:stylelint --syntax scss ...
- If you're using the Node API, pass in the
syntax
option like so:stylelint.lint({ syntax: "sugarss", ... })
.
If you're using the linter as a PostCSS Plugin, you'll need to use the special parser directly with PostCSS's syntax
option like so:
var postcss = require("postcss")
var scss = require("postcss-scss")
// or use "postcss-less" or "sugarss"
postcss([
require("stylelint"),
require("reporter")
])
.process(css, {
from: "src/app.css",
syntax: scss
})
})