diff options
Diffstat (limited to 'assets/node_modules/stylelint/docs/user-guide/css-processors.md')
-rw-r--r-- | assets/node_modules/stylelint/docs/user-guide/css-processors.md | 44 |
1 files changed, 44 insertions, 0 deletions
diff --git a/assets/node_modules/stylelint/docs/user-guide/css-processors.md b/assets/node_modules/stylelint/docs/user-guide/css-processors.md new file mode 100644 index 0000000..f0c56d1 --- /dev/null +++ b/assets/node_modules/stylelint/docs/user-guide/css-processors.md @@ -0,0 +1,44 @@ +# CSS processors + +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: + +1. *Before*: Some plugins/processors might enable a syntax that isn't compatible with the linter. +2. *After*: Some plugins/processors might generate CSS that is invalid against your linter config, causing violations 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. + +## Parsing non-standard syntax + +stylelint will automatically infer the syntax from the: + +- file extension +- `type` or `lang` attribute on `<style>` tags in HTML (and HTML-like) +- [info string](https://github.github.com/gfm/#info-string) on [GFM fenced code blocks](https://help.github.com/articles/creating-and-highlighting-code-blocks/) in Markdown + +You can force a specific syntax, though. Both the [CLI](cli.md) and the [Node.js API](node-api.md) 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.js API, pass in the `syntax` option like so: `stylelint.lint({ syntax: "sugarss", ... })`. + +stylelint can also accept a custom [PostCSS-compatible syntax](https://github.com/postcss/postcss#syntaxes) when using the CLI or Node.js API. For custom syntaxes, use the `custom-syntax` and `customSyntax` options, respectively. + +- If you're using the CLI, use the `custom-syntax` flag like so: `stylelint ... --custom-syntax custom-syntax-module` or `stylelint ... --custom-syntax ./path/to/custom-syntax-module`. +- If you're using the Node.js API, pass in the `customSyntax` option like so: `stylelint.lint({ customSyntax: path.join(process.cwd(), './path/to/custom-syntax-module') , ... })`. + +If you're using the linter as a [PostCSS Plugin](postcss-plugin.md), you should use the special `postcss-syntax` directly with PostCSS's `syntax` option like so: + +```js +const postcss = require('postcss'); +const syntax = require('postcss-syntax'); + +postcss([ + require('stylelint'), + require('reporter'), +]) + .process(css, { + from: 'lib/app.css', + syntax: syntax, + }); +``` |