.config/coc/extensions/node_modules/coc-prettier/node_modules/stylelint/docs/user-guide/faq.md

   1 # FAQ
   2
   3 ## How do I turn off, disable or ignore a rule?
   4
   5 You can turn off a rule by setting its config value to `null`.
   6
   7 For example, to use `stylelint-config-standard` without the `at-rule-empty-line-before` rule:
   8
   9 ```json
  10 {
  11   "extends": "stylelint-config-standard",
  12   "rules": {
  13     "at-rule-empty-line-before": null
  14   }
  15 }
  16 ```
  17
  18 You can also turn off a rule for specific sections of your CSS. Refer to the rules section of the [configuration guide](configuration.md#rules) for more information.
  19
  20 ## How do I lint from the command line?
  21
  22 Refer to the [CLI section](cli.md) of the docs.
  23
  24 The CLI can also be used from within [npm run scripts](https://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/) to use a non-global installation of stylelint.
  25
  26 ## How do I lint using Git pre-commit hooks?
  27
  28 [lint-staged](https://github.com/okonet/lint-staged) is a NodeJS script that supports running stylelint against Git staged files.
  29
  30 ## How do I lint using my task runner of choice?
  31
  32 The stylelint community maintains a [handful of plugins](complementary-tools.md#build-tool-plugins) for popular task runners, including ones for gulp, webpack, Broccoli and Grunt. Refer to their individual READMEs to get started.
  33
  34 If there isn't a dedicated stylelint plugin for your task runner of choice, you can use stylelint as a PostCSS plugin and make use of PostCSS's [numerous](https://github.com/postcss/postcss#runners) task runner plugins.
  35
  36 There are also examples of using the PostCSS plugin via the PostCSS JS API within the [docs](postcss-plugin.md).
  37
  38 However, using stylelint as a PostCSS plugin limits your reporting options to [postcss-reporter](https://github.com/postcss/postcss-reporter/). We recommend using the stylelint CLI or Node API, instead, for better reporting.
  39
  40 ## How do I lint within my text editor?
  41
  42 The stylelint community also maintains a [handful of plugins](complementary-tools.md#editor-plugins) for popular editors. Refer to their individual READMEs to get started.
  43
  44 ## How do I lint SCSS, Less, or other non-standard syntax?
  45
  46 stylelint can *parse* any the following non-standard syntaxes by default: SCSS, Less and SugarSS. Non-standard syntaxes can automatically be inferred from the following file extensions `.scss`, `.less`, and `.sss`; or else you can specify the syntax yourself.
  47
  48 Additionally, stylelint can accept any [PostCSS-compatible syntax](https://github.com/postcss/postcss#syntaxes) when using the CLI or Node API. Note, however, that stylelint can provide no guarantee that core rules will work with syntaxes other than the defaults listed above.
  49
  50 Refer to the [docs](css-processors.md#parsing-non-standard-syntax) on how to configure stylelint to parse non-standard syntaxes.
  51
  52 ## Should I lint before or after processing my stylesheets through PostCSS plugins or other processors?
  53
  54 We [recommend](css-processors.md) linting your source files before any transformations.
  55
  56 ## How do I lint styles within `<style>` tags?
  57
  58 [Create a processor](../developer-guide/processors.md) or [use an existing one](configuration.md#processors) that extracts CSS from your HTML's `<style>` tags and feeds it into stylelint.
  59
  60 ## How do I automatically fix stylistic violations?
  61
  62 Use the `--fix` CLI flag or the `fix` Node API option to fix a number of stylistic violations with this *experimental* feature.
  63
  64 ## How do I manage conflicts between rules?
  65
  66 Each rule stands alone, so sometimes it's possible to configure rules such that they conflict with one another. For example, you could turn on two conflicting blacklist and whitelist rules, e.g. `unit-blacklist` and `unit-whitelist`.
  67
  68 It's your responsibility as the configuration author to resolve these conflicts.
  69
  70 ## What is the difference between a plugin and a rule?
  71
  72 A rule must meet the [criteria](../developer-guide/rules.md) set out in the developer guide, including being applicable to only standard CSS syntax, and having a clear and unambiguous finished state. Whereas a plugin is a rule or sets of rules built by the community that don't adhere to the criteria. It might support a particular methodology or toolset, or apply to *non-standard* constructs and features, or be for specific use cases.
  73
  74 For example, we've found that rules to enforce property order, property groupings, etc., work better as plugins, because there are so many different opinions about what to enforce, and how. When you write or use a plugin, you can make sure to enforce your own particular preferences, exactly; but a rule that tries to address too many divergent use-cases becomes a mess.
  75
  76 Plugins are easy to incorporate into your configuration.
  77
  78 ## Can I customise stylelint's messages?
  79
  80 Yes, you can either use the [`message` secondary option](configuration.md#custom-messages) or [write your own formatter](../developer-guide/formatters.md).
  81
  82 ## How should I lint my CSS that follows a BEM-like methodology?
  83
  84 Use the [stylelint-selector-bem-pattern](https://github.com/davidtheclark/stylelint-selector-bem-pattern) plugin to ensure your selectors conform to a chosen BEM-flavor pattern.
  85
  86 You can also take advantage of the `selector-*` rules to ban certain types of selectors (e.g. id selectors) and control specificity.
  87
  88 If you're using SUITCSS, you might want to use [their shareable config](https://github.com/suitcss/stylelint-config-suitcss).
  89
  90 ## How do I disallow single-line blocks?
  91
  92 ```css
  93   a { color: red; }
  94 /** ↑
  95  * Declaration blocks like this */
  96 ```
  97
  98 Use the `block-opening-brace-newline-after` and `block-opening-brace-newline-before` rules together. For example, this config:
  99
 100 ```json
 101 {
 102   "block-opening-brace-newline-after": ["always"],
 103   "block-closing-brace-newline-before": ["always"]
 104 }
 105 ```
 106
 107 Would allow:
 108
 109 ```css
 110 a {
 111   color: red;
 112 }
 113 ```
 114
 115 But not these patterns:
 116
 117 ```css
 118 a { color: red;
 119 }
 120
 121 a {
 122 color: red; }
 123
 124 a { color: red; }
 125 ```
 126
 127 To allow single-line blocks but enforce newlines with multi-line blocks, use the `"always-multi-line"` option for both rules.
 128
 129
 130 ## How do I configure the `*-pattern` rules for common CSS naming conventions like kebab-case?
 131
 132 Use the regex that corresponds to your chosen convention:
 133
 134 -   kebab-case: `^([a-z][a-z0-9]*)(-[a-z0-9]+)*$`
 135 -   lowerCamelCase: `^[a-z][a-zA-Z0-9]+$`
 136 -   snake\_case: `^([a-z][a-z0-9]*)(_[a-z0-9]+)*$`
 137 -   UpperCamelCase: `^[A-Z][a-zA-Z0-9]+$`
 138
 139 e.g. for lowerCamelCase class selectors, use `"selector-class-pattern": "^[a-z][a-zA-Z0-9]+$"`.
 140
 141 All these patterns disallow CSS identifiers that start with a digit, two hyphens, or a hyphen followed by a digit.
 142
 143 ## How do I change the default severity to "warning" so stylelint doesn't break my build?
 144
 145 Use the [`defaultSeverity`](configuration.md#defaultseverity) configuration option.
 146
 147 ## Can I bundle more than one sharable config within an npm package?
 148
 149 A user can `require()` any file in your npm package, so all you need to do is document which paths point to configs (e.g. `require('my-package/config-2')`).
 150
 151 ## How can I control the whitespace after the open brace of the block?
 152
 153 Refer to [this](about-rules.md#-empty-line-before-and--max-empty-lines-rules) section of the docs that explains how the `*-empty-line-before` rules work.
 154
 155 ## If I use `extends` within my configuration object, will the options for each rule be merged or overridden?
 156
 157 They will be overridden.
 158
 159 The `extends` mechanism is [detailed within the configuration docs](configuration.md#extends):
 160
 161 > When one configuration extends another, it starts with the other's properties then adds to and overrides what's there.
 162
 163 The reason for this design is documented in [#1646](https://github.com/stylelint/stylelint/issues/1646#issuecomment-232779957).