steve/just-the-docs
1
0
Fork 0
mirror of https://github.com/snachodog/just-the-docs.git synced 2025-09-12 21:03:32 -06:00
Code Issues Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Patrick Marsceill
2017-03-09 13:16:08 -05:00
commit b7b0d0d7bf
4147 changed files with 401224 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
node_modules/stylelint/docs/developer-guide.md generated vendored Normal file
View File

@@ -0,0 +1,7 @@
# Developer guide
- [Rules](developer-guide/rules.md): Working on stylelint's rules.
- [Plugins](developer-guide/plugins.md): Writing your own plugins.
- [Processors](developer-guide/processors.md): Writing your own processors.
- [Formatters](developer-guide/formatters.md): Writing your own formatters.
- [Rule testers](developer-guide/rule-testers.md): Using and writing rule testers.

37
node_modules/stylelint/docs/developer-guide/formatters.md generated vendored Normal file
View File

@@ -0,0 +1,37 @@
# Writing formatters
A formatter is a function that accepts *an array of these stylelint result objects* and outputs a string:
```js
// A stylelint result object
{
source: "path/to/file.css", // The filepath or PostCSS identifier like <input css 1>
errored: true, // This is `true` if at least one rule with an "error"-level severity triggered a warning
warnings: [ // Array of rule violation warning objects, each like the following ...
{
line: 3,
column: 12,
rule: "block-no-empty",
severity: "error",
text: "You should not have an empty block (block-no-empty)"
},
..
],
deprecations: [ // Array of deprecation warning objects, each like the following ...
{
text: "Feature X has been deprecated and will be removed in the next major version.",
reference: "https://stylelint.io/docs/feature-x.md"
}
],
invalidOptionWarnings: [ // Array of invalid option warning objects, each like the following ...
{
text: "Invalid option X for rule Y",
}
],
ignored: false // This is `true` if the file's path matches a provided ignore pattern
}
```
## `stylelint.formatters`
stylelint's internal formatters are exposed publicly in `stylelint.formatters`.

142
node_modules/stylelint/docs/developer-guide/plugins.md generated vendored Normal file
View File

@@ -0,0 +1,142 @@
# Writing plugins
Plugins are rules and sets of rules built by the community.
We recommend familiarising yourself and adhering to stylelint's [conventions for writing rules](rules.md), including those for names, options, messages, tests and docs.
## The anatomy of a plugin
```js
// Abbreviated example
var stylelint = require("stylelint")
var ruleName = "plugin/foo-bar"
var messages = stylelint.utils.ruleMessages(ruleName, {
expected: "Expected ...",
})
module.exports = stylelint.createPlugin(ruleName, function(primaryOption, secondaryOptionObject) {
return function(postcssRoot, postcssResult) {
var validOptions = stylelint.utils.validateOptions(postcssResult, ruleName, { .. })
if (!validOptions) { return }
// ... some logic ...
stylelint.utils.report({ .. })
}
})
module.exports.ruleName = ruleName
module.exports.messages = messages
```
Your plugin's rule name must be namespaced, e.g. `your-namespace/your-rule-name`. If your plugin provides only a single rule or you can't think of a good namespace, you can simply use `plugin/my-rule`. This namespace ensures that plugin rules will never clash with core rules. *Make sure you document your plugin's rule name (and namespace) for users, because they will need to use it in their config.*
`stylelint.createPlugin(ruleName, ruleFunction)` ensures that your plugin will be setup properly alongside other rules.
In order for your plugin rule to work with the [standard configuration format](../user-guide/configuration.md#rules), `ruleFunction` should accept 2 arguments: the primary option and, optionally, an secondary options object.
`ruleFunction` should return a function that is essentially a little [PostCSS plugin](https://github.com/postcss/postcss/blob/master/docs/writing-a-plugin.md): it takes 2 arguments: the PostCSS Root (the parsed AST), and the PostCSS LazyResult. You'll have to [learn about the PostCSS API](https://github.com/postcss/postcss/blob/master/docs/api.md).
## `stylelint.utils`
stylelint exposes some utilities that are useful. *For details about the APIs of these functions, please look at comments in the source code and examples in the standard rules.*
### `stylelint.utils.report`
Adds warnings from your plugin to the list of warnings that stylelint will report to the user.
*Do not use PostCSS's `node.warn()` method directly.* When you use `stylelint.utils.report`, your plugin will respect disabled ranges and other possible future features of stylelint, providing a better user-experience, one that better fits the standard rules.
### `stylelint.utils.ruleMessages`
Tailors your messages to the format of standard stylelint rules.
### `stylelint.utils.validateOptions`
Validates the options for your rule.
### `stylelint.utils.checkAgainstRule`
Checks CSS against a standard stylelint rule *within your own rule*. This function provides power and flexibility for plugins authors who wish to modify, constrain, or extend the functionality of existing stylelint rules.
Accepts an options object and a callback that is invoked with warnings from the specified rule. The options are:
- `ruleName`: The name of the rule you are invoking.
- `ruleSettings`: Settings for the rule you are invoking, formatting in the same way they would be in a `.stylelintrc` configuration object.
- `root`: The root node to run this rule against.
Use the warning to create a *new* warning *from your plugin rule* that you report with `stylelint.utils.report`.
For example, imagine you want to create a plugin that runs `at-rule-no-unknown` with a built-in list of exceptions for at-rules provided by your preprocessor-of-choice:
```js
const allowableAtRules = [..]
function myPluginRule(primaryOption, secondaryOptions) {
return (root, result) => {
const defaultedOptions = Object.assign({}, secondaryOptions, {
ignoreAtRules: allowableAtRules.concat(options.ignoreAtRules || []),
})
stylelint.utils.checkAgainstRule({
ruleName: 'at-rule-no-unknown',
ruleSettings: [primaryOption, defaultedOptions],
root: root
}, (warning) => {
stylelint.utils.report({
message: myMessage,
ruleName: myRuleName,
result: result,
node: warning.node,
line: warning.line,
column: warning.column,
})
})
}
}
```
## `stylelint.rules`
All of the rule functions are available at `stylelint.rules`. This allows you to build on top of existing rules for your particular needs.
A typical use-case is to build in more complex conditionals that the rule's options allow for. For example, maybe your codebase uses special comment directives to customize rule options for specific stylesheets. You could build a plugin that checks those directives and then runs the appropriate rules with the right options (or doesn't run them at all).
All rules share a common signature. They are a function that accepts two arguments: a primary option and a secondary options object. And that functions returns a function that has the signature of a PostCSS plugin, expecting a PostCSS root and result as its arguments.
Here's a simple example of a plugin that runs `color-hex-case` only if there is a special directive `@@check-color-hex-case` somewhere in the stylesheet:
```js
export default stylelint.createPlugin(ruleName, function (expectation) {
const runColorHexCase = stylelint.rules["color-hex-case"](expectation)
return (root, result) => {
if (root.toString().indexOf("@@check-color-hex-case") === -1) return
runColorHexCase(root, result)
}
})
```
## Allow primary option arrays
If your plugin can accept an array as its primary option, you must designate this by setting the property `primaryOptionArray = true` on your rule function. For more information, check out the ["Working on rules"](rules.md#primary) doc.
## External helper modules
In addition to the standard parsers mentioned in the ["Working on rules"](rules.md) doc, there are other external modules used within stylelint that we recommend using. These include:
- [normalize-selector](https://github.com/getify/normalize-selector): Normalize CSS selectors.
- [postcss-resolve-nested-selector](https://github.com/davidtheclark/postcss-resolve-nested-selector): Given a (nested) selector in a PostCSS AST, return an array of resolved selectors.
- [style-search](https://github.com/davidtheclark/style-search): Search CSS (and CSS-like) strings, with sensitivity to whether matches occur inside strings, comments, and functions.
Have a look through [stylelint's internal utils](https://github.com/stylelint/stylelint/tree/master/lib/utils) and if you come across one that you need in your plugin, then please consider helping us extract it out into a external module.
## Testing plugins
For testing your plugin, you might consider using the same rule-testing function that stylelint uses internally: [`stylelint-test-rule-tape`](https://github.com/stylelint/stylelint-test-rule-tape).
## Plugin packs
To make a single module provide multiple rules, simply export an array of plugin objects (rather than a single object).
## Sharing plugins and plugin packs
- Use the `stylelint-plugin` keyword within your `package.json`.
- Once your plugin is published, please send us a Pull Request to add your plugin to [the list](../user-guide/plugins.md).

39
node_modules/stylelint/docs/developer-guide/processors.md generated vendored Normal file
View File

@@ -0,0 +1,39 @@
# Writing processors
Processors are functions that hook into stylelint's pipeline, modifying code on its way into stylelint and modifying results on their way out.
*Processors can only be used with the CLI and the Node API, not with the PostCSS plugin.*
Processor modules are functions that accept an options object and return an object with the following the functions, which hook into the processing of each file:
- **code**: A function that accepts two arguments, the file's code and the file's path, and returns a string for stylelint to lint.
- **result**: A function that accepts two arguments, the file's stylelint result object and the file's path, and either mutates the result object (returning nothing) or returns a new one.
```js
// my-processor.js
module.exports = function(options) {
return {
code: function(input, filepath) {
// ...
return transformedCode;
},
result: function(stylelintResult, filepath) {
// ...
return transformedResult;
}
};
}
```
Processors can enable stylelint to lint the CSS within non-stylesheet files. For example, let's say you want to lint the CSS within `<style>` tags in HTML. If you just feed stylelint your HTML code, you'll run into problems, because PostCSS does not parse HTML. Instead, you can create a processor that does the following:
- In the `code` processor function, extract CSS from the `<style>` tags in the HTML code. Return a CSS string containing all that extracted CSS, which is what stylelint will inspect.
- Build a sourcemap while performing the extraction, so warning positions can be tailored to match the original source HTML.
- In the `result` processor function, modify the line/column position of each warning using your sourcemap.
*Processor options must be JSON-friendly*, because users will need to include them in `.stylelintrc` files.
## Sharing processors
- Use the `stylelint-processor` keyword within your `package.json`.
- Once your processor is published, please send us a Pull Request to add your processor to [the list](../user-guide/processors.md).

88
node_modules/stylelint/docs/developer-guide/rule-testers.md generated vendored Normal file
View File

@@ -0,0 +1,88 @@
# Rule testers
stylelint rules require *a lot* of tests. So we've built a specialized stylelint rule testing format to speed up the mass production of consistent, effective rule tests.
There is a schema for describing tests, and a function for creating "rule testers" that interpret that schema using a test framework (e.g. tape or Mocha).
When developing plugins, you can use the following rule testers or create your own.
- stylelint-test-rule-tape
- stylelint-test-rule-mocha
- stylelint-test-rule-ava
## Using a rule tester
To use the rule tester of your choice, do the following:
```js
// `testRule` = the imported rule tester
testRule(rule, testGroupDescription)
```
`rule` is just the rule that you are testing (a function).
`testGroupDescription` is an object fitting the following schema.
### The test group schema
Each test group object describes a set of test-cases for a certain rule with a certain configuration.
Required properties:
- `ruleName` {string}: The name of the rule. Used in generated test-case descriptions.
- `config` {any}: The rule's configuration for this test group. Should match the rule configuration format you'd use in `.stylelintrc`.
- `accept` {array}: An array of objects describing test cases that *should not violate the rule*. Each object has these properties:
- `code` {string}: The source CSS to check.
- `description` {string}: *Optional.* A description of the case.
- `only` {boolean}: If `true`, run only this test case.
- `reject` {array}: An array of objects describing test cases that *should violate the rule once*. Each object has these properties:
- `code` {string}: The source CSS to check.
- `message` {string}: The message of the expected violation.
- `line` {number}: *Optional but recommended.* The expected line number of the violation. If this is left out, the line won't be checked.
- `column` {number}: *Optional but recommended.* The expected column number of the violation. If this is left out, the column won't be checked.
- `description` {string}: *Optional.* A description of the case.
- `only` {boolean}: If `true`, run only this test case.
Optional properties:
- `syntax` {"css"|"less"|"scss"|"sugarss"}: Defaults to `"css"`. Other settings use special parsers.
- `skipBasicChecks` {boolean}: Defaults to `false`. If `true`, a few rudimentary checks (that should almost always be included) will not be performed. You can check those out in `lib/testUtils/basicChecks.js`.
- `preceedingPlugins` {array}: An array of PostCSS plugins that should be run before the CSS is tested.
## Creating a rule tester
stylelint itself exposes a means of creating rule testers with just about any testing framework.
```js
var testRule = stylelint.createRuleTester(equalityCheck)
```
Pass in an `equalityCheck` function. Given some information, this checker should use whatever test runner you like to perform equality checks.
The `equalityCheck` function should accept two arguments:
- `processCss` {Promise}: A Promise that resolves with an array of comparisons that you need to check (documented below).
- `context` {object}: An object that contains additional information you may need:
- `caseDescription` {string}: A description of the test case as whole. It will end up printing like something this:
```bash
> rule: value-list-comma-space-before
> config: "always-single-line"
> code: "a { background-size: 0 ,0;\n}"
```
- `comparisonCount` {number}: The number of comparisons that will need to be performed (e.g. useful for tape).
- `completeAssertionDescription` {string}: While each individual comparison may have its own description, this is a description of the whole assertion (e.g. useful for Mocha).
- `only` {boolean}: If `true`, the test runner should only run this test case (e.g. `test.only` in tape, `describe.only` in Mocha).
`processCss` is a Promise that resolves with an array of comparisons. Each comparison has the following properties:
- `actual` {any}: Some actual value.
- `expected` {any}: Some expected value.
- `description` {string}: A (possibly empty) description of the comparison.
Within the `equalityCheck` function, you need to ensure that you do the following:
- Set up the test case.
- When `processCss` resolves, loop through every comparison.
- For each comparison, make an assertion checking that `actual === expected`.
A `testRule` function (as described above) is returned.

260
node_modules/stylelint/docs/developer-guide/rules.md generated vendored Normal file
View File

@@ -0,0 +1,260 @@
# Working on rules
**Please help us create, enhance, and debug stylelint rules!**
There are well over a hundred rules already, so stylelint *needs* community contributions to continue to improve.
If you like stylelint and open source software (since you're reading this, you almost certainly do), please consider taking some time to pitch in. Not only will you help stylelint thrive, you will also learn a thing or two — about CSS, PostCSS, Node, ES2015, unit testing, open source software, and more.
**We want to do everything we can to encourage contributions!** So if you want to participate but don't end up doing it for one reason or another, please file an issue and give us feedback about what we could do to better encourage you.
Also: we hope that your participation in the project isn't a one-off. *We'd love to add more members to the organization and see more regulars pop up in issues and pull requests!*
## Creating a new rule
First, open [an issue](https://github.com/stylelint/stylelint/issues/new) with your idea for the new rule.
Usually we have some discussion about the rule's purpose, name, options, and suitability as a rule.
### Criteria for inclusion
We discuss whether the rule meets the following criteria for inclusion in stylelint:
- Applicable to standard CSS syntax only.
- Generally useful; not tied to idiosyncratic patterns.
- Has a clear and unambiguous finished state.
- Has a singular purpose.
- Is standalone, and doesn't rely on another rule.
- Does not contain functionality that overlaps with another rule.
Otherwise, it should be a plugin. However, plugins should also try to adhere to the latter three criteria.
### Naming a rule
Have a look at the [rules user guide](../user-guide/about-rules.md) to familiarize yourself the rule naming conventions.
We take care to ensure that all the rules are named accurately and consistently. Our goals in that effort are to ensure that rules are easy to find and understand, and to prevent us from wanting to change the name later.
*Rules are named to encourage explicit, rather than implicit, options.* For example, `color-hex-case: "upper"|"lower"` rather than `color-hex-uppercase: "always"|"never"`. As `color-hex-uppercase: "never"` *implies* always lowercase, whereas `color-hex-case: "lower"` makes it *explicit*.
### Determining options
#### Primary
Every rule *must have* a **primary option**.
- In `"color-hex-case": "upper"`, the primary option is `"upper"`.
- In `"indentation": [2, { "except": ["block"] }]`, the primary option is `2`.
If your rule can accept an array as its primary option, you must designate this by setting the property `primaryOptionArray = true` on your rule function. For example:
```js
function rule(primary, secondary) {
return (root, result) => {..}
}
rule.primaryOptionArray = true
export default rule
// or, for plugins: stylelint.createPlugin(ruleName, rule)
```
There is one caveat here: If your rule accepts a primary option array, it cannot also accept a primary option object. Whenever possible, if you want your rule to accept a primary option array, you should just make an array the only possibility, instead of allowing for various data structures.
#### Secondary
Some rules require extra flexibility to address a variety of use-cases. These can use an **optional secondary options object**.
- In `"color-hex-case": "upper"`, there is no secondary options object.
- In `"indentation": [2, { "except": ["block"] }]`, the secondary options object is `{ "except": ["block"] }`.
The most typical secondary options are `"ignore": []` and `"except": []`; but anything is possible.
A rule's secondary option can be anything if you're not ignoring or making exceptions. As an example, `resolveNestedSelectors: true|false` is used within some `selector-*` rules to change how the rule processes nested selectors.
##### Keyword `"ignore"` and `"except"`
`"ignore"` and `"except"` accept an array of predefined keyword options e.g. `["relative", "first-nested", "descendant"]`.
- Use `"ignore"` when you want the rule to simply skip-over a particular pattern.
- Use `"except"` when you want to invert the primary option for a particular pattern.
##### User-defined `"ignore*"`
Use a more specific secondary option name when accepting a *user-defined* list of things to ignore. This takes the form of `"ignore<Things>": []` e.g. use `"ignoreAtRules": []` if a rule checks at-rules and you want to allow a user to specify which particular at-rule types to ignore.
### Determine warning messages
Messages take one of these forms:
- "Expected \[something\] \[in some context\]".
- "Unexpected \[something\] \[in some context\]."
Look at the messages of other rules to glean more conventions and patterns.
### Write the rule
*When writing the rule, always look to other similar rules for conventions and patterns to start from and mimic.*
You will use the simple [PostCSS API](http://api.postcss.org/) to navigate and analyze the CSS syntax tree. We recommend using the `walk` iterators (e.g. `walkDecls`), rather than using `forEach` to loop through the nodes.
Depending on the rule, we also recommend using [postcss-value-parser](https://github.com/TrySound/postcss-value-parser) and [postcss-selector-parser](https://github.com/postcss/postcss-selector-parser). There are significant benefits to using these parsers instead of regular expressions or `indexOf` searches (even if they aren't always the most performant method).
stylelint has a number of [utility functions](https://github.com/stylelint/stylelint/tree/master/lib/utils) that are used in existing rules and might prove useful to you, as well. Please look through those so that you know what's available. (And if you have a new function that you think might prove generally helpful, let's add it to the list!)
In particular, you will definitely want to use `validateOptions()` so that users are warned about invalid options. (Looking at other rules for examples of options validation will help a lot.)
### Write tests
Each rule must be accompanied by tests that contain:
- All patterns that are considered warnings.
- All patterns that should *not* be considered warnings.
It is easy to write stylelint tests, so *write as many as you can stand to*.
#### Checklist
Please run through this checklist and ensure each point is covered by your tests. Especially *consider the edge-cases*. These are where the bugs and shortcomings of rules always arise.
##### Best practices
- Ensure you are testing errors in multiple positions, not the same place every time.
- Ensure you use realistic (if simple) CSS, and avoid the use of ellipses.
- Ensure you use standard CSS syntax by default, and only swap parsers when testing a specific piece of non-standard syntax.
- When accessing raw strings from the PostCSS AST, use `node.raws` instead of `node.raw()`. This will ensure string corresponds exactly to the original.
##### Commonly overlooked edge-cases
- How does your rule handle variables (`$sass`, `@less`, or `var(--custom-property)`)?
- How does your rule handle CSS strings (e.g. `content: "anything goes";`)?
- How does your rule handle CSS comments (e.g. `/* anything goes */`)?
- How does your rule handle `url()` functions, including data URIs (e.g. `url(anything/goes.jpg)`)?
- How does your rule handle vendor prefixes (e.g. `@-webkit-keyframes name {}`)?
- How does your rule handle case sensitivity (e.g. `@KEYFRAMES name {}`)?
- How does your rule handle a pseudo-class *combined* with a pseudo-element (e.g. `a:hover::before`)?
- How does your rule handle nesting (e.g. do you resolve `& a {}`, or check it as is?)?
- How does your rule handle whitespace and punctuation (e.g. comparing `rgb(0,0,0)` with `rgb(0, 0, 0)`)?
#### Running tests
You can run the tests via:
```console
npm test
```
However, this runs all 25,000+ unit tests and also linting.
You can use the interactive testing prompt to run tests for just a chosen set of rules (which you'll want to do during development). For example, to run the tests for just the `color-hex-case` and `color-hex-length` rules:
1. Use `npm run watch` to start the prompt.
2. Press `p` to filter by a filename regex pattern.
3. Enter `color-hex-case|color-hex-length` i.e. each rule name separated by the pipe symbol (`|`).
### Write the README
Each rule must be accompanied by a README, fitting the following format:
1. Rule name.
2. Single line description.
3. Prototypical code example.
4. Expanded description (if necessary).
5. Options.
6. Example patterns that are considered warnings (for each option value).
7. Example patterns that are *not* considered warnings (for each option value).
8. Optional options (if applicable).
Look at the READMEs of other rules to glean more conventional patterns.
#### Single line descriptions
Take the form of:
- "Disallow ..." (for `no` rules).
- "Limit ..." (for `max` rules).
- "Require ..." (for rules that accept `"always"` and `"never"` options).
- "Specify ..." (for everything else).
#### Example patterns
- Use complete CSS patterns i.e. avoid ellipses (`...`)
- Use standard CSS syntax (and use `css` code fences) by default.
- Use the minimum amount of code possible to communicate the patten e.g. if the rule targets selectors then use an empty rule e.g. `{}`.
- Use `{}`, rather than `{ }` for empty rules.
- Use the `a` type selector by default.
- Use the `@media` at-rules by default.
- Use the `color` property by default.
- Use *foo*, *bar* and *baz* for names e.g. `.foo`, `#bar` `--baz`
### Wire up the rule
The final step is to add references to the new rule in the following places:
- [The rules `index.js` file](https://github.com/stylelint/stylelint/blob/master/lib/rules/index.js)
- [The list of rules](../user-guide/rules.md)
- [The example config](../user-guide/example-config.md)
Once you have something to show, you'll create a [pull request](https://github.com/stylelint/stylelint/compare) to continue the conversation.
## Adding a option to an existing rule
First, open [an issue](https://github.com/stylelint/stylelint/issues/new) about the option you wish to add. We'll discuss its functionality and name there.
Once we've agreed on the direction, you can work on a pull request. Here are the steps you'll need to take:
1. Change the rule's validation to allow for the new option.
2. Add to the rule some logic (as little as possible) to make the option work.
3. Add new unit tests to test the option.
4. Add documentation about the new option.
## Fixing a bug in an existing rule
Fixing bugs is usually very easy. Here is a process that works:
1. Write failing unit tests that exemplify the bug.
2. Fiddle with the rule until those new tests pass.
That's it! **If you are unable to figure out how to fix the bug yourself, it is still *extremely* helpful to submit a pull request with your failing test cases.** It means that somebody else can jump right in and help out with the rule's logic.
## Improving the performance of a new or an existing rule
There's a simple way to run benchmarks on any given rule with any valid config for it:
```shell
npm run benchmark-rule -- [rule-name] [config]
```
If the `config` argument is anything other than a string or a boolean, it must be valid JSON wrapped in quotation marks.
```shell
npm run benchmark-rule -- selector-combinator-space-after never
```
```shell
npm run benchmark-rule -- selector-combinator-space-after always
```
```shell
npm run benchmark-rule -- selector-no-combinator true
```
```shell
npm run benchmark-rule -- block-opening-brace-space-before "[\"always\", {\"ignoreAtRules\": [\"else\"]}]"
```
The script loads Bootstrap's CSS (from its CDN) and runs it through the configured rule.
It will end up printing some simple stats like this:
```shell
Warnings: 1441
Mean: 74.17598357142856 ms
Deviation: 16.63969674310928 ms
```
What can you do with this? **When writing new rules or refactoring existing rules, use these measurements to determine the efficiency of your code.**
A stylelint rule can repeat it's core logic many, many times (e.g. checking every value node of every declaration in a vast CSS codebase). So it's worth paying attention to performance and doing what we can to improve it!
**This is a great way to contribute if you just want a quick little project.** Try picking a rule and seeing if there's anything you can do to speed it up.
Make sure to include benchmark measurements in your PR's!

15
node_modules/stylelint/docs/user-guide.md generated vendored Normal file
View File

@@ -0,0 +1,15 @@
# User guide
- [The CLI](user-guide/cli.md): Examples and exit codes for using the CLI.
- [The Node API](user-guide/node-api.md): Options and examples for using the Node API.
- [The PostCSS plugin](user-guide/postcss-plugin.md): Options and examples for using the PostCSS plugin.
- [Configuration](user-guide/configuration.md): How to configure stylelint.
- [Example config](user-guide/example-config.md): An example config that you can use as a blueprint for your own.
- [CSS processors](user-guide/css-processors.md): How to use the linter with a CSS processor, like SCSS or PostCSS plugins.
- [About rules](user-guide/about-rules.md): An explanation of rule names and how rules work together.
- [Rules](user-guide/rules.md): A list of stylelint's rules.
- [Plugins](user-guide/plugins.md): A list of community plugins.
- [Processors](user-guide/processors.md): A list of community processors.
- [Complementary tools](user-guide/complementary-tools.md): List of community editor plugins, build tool plugins and other tools.
- [FAQ](user-guide/faq.md): Frequently asked questions about using and configuring stylelint.
- [Articles](user-guide/articles.md): A collection of articles and tutorials about stylelint.

388
node_modules/stylelint/docs/user-guide/about-rules.md generated vendored Normal file
View File

@@ -0,0 +1,388 @@
# About rules
We have taken great care to consistently name rules.
The rules have been designed to work in conjunction with one another so that strict conventions can be enforced.
## About rule names
- Made of lowercase words separated by hyphens.
- Split into two parts:
- The first describes what [*thing*](http://apps.workflower.fi/vocabs/css/en) the rule applies to.
- The second describes what the rule is checking.
```js
"number-leading-zero"
// ↑ ↑
// the thing what the rule is checking
```
- Except when the rule applies to the whole stylesheet:
```js
"no-eol-whitespace"
"indentation"
// ↑
// what the rules are checking
```
### No rules
Most rules allow you to choose whether you want to require *or* disallow something.
For example, whether numbers *must* or *must not* have a leading zero:
- `number-leading-zero`: `string - "always"|"never"`
- `"always"` - there *must always* be a leading zero.
- `"never"` - there *must never* be a leading zero.
```css
a { line-height: 0.5; }
/** ↑
* This leading zero */
```
However, some rules *just disallow* something. `*-no-*` is used to identify these rules.
For example, whether empty blocks should be disallowed:
- `block-no-empty` - blocks *must not* be empty.
```css
a { }
/** ↑
* Blocks like this */
```
Notice how, for a rule like this, it does not make sense to have an option to enforce the opposite i.e. that every block *must* be empty.
### Max rules
`*-max-*` is used when a rule is *setting a limit* to something.
For example, specifying the maximum number of digits after the "." in a number:
- `number-max-precision`: `int`
```css
a { font-size: 1.333em; }
/** ↑
* The maximum number of digits after this "." */
```
### Whitespace rules
Whitespace rules allow you to specify whether an empty line, a single space, a newline or no space must be used in some specific part of the stylesheet.
The whitespace rules combine two sets of keywords:
1. `before`, `after` and `inside` are used to specify where the whitespace (if any) is expected.
2. `empty-line`, `space` and `newline` are used to specify whether a single empty line, a single space, a single newline or no space is expected there.
For example, specifying if a single empty line or no space must come before all the comments in a stylesheet:
- `comment-empty-line-before`: `string` - `"always"|"never"`
```css
a {}
←
/* comment */ ↑
↑
/** ↑
* This empty line */
```
Additionally, some whitespace rule make use of another set of keywords:
1. `comma`, `colon`, `semicolon`, `opening-brace`, `closing-brace`, `opening-parenthesis`, `closing-parenthesis`, `operator` or `range-operator` are used if a specific piece of punctuation in the *thing* is being targetted.
For example, specifying if a single space or no space must come after a comma in a function:
- `function-comma-space-after`: `string` - `"always"|"never"`
```css
a { transform: translate(1, 1) }
/** ↑
* The space after this commas */
```
The plural of the punctuation is used for `inside` rules. For example, specifying if a single space or no space must be inside the parentheses of a function:
- `function-parentheses-space-inside`: `string` - `"always"|"never"`
```css
a { transform: translate( 1, 1 ); }
/** ↑ ↑
* The space inside these two parentheses */
```
## Rules work together
The rules can be used together to enforce strict conventions.
### `*-newline/space-before` and `*-newline/space-after` rules
Say you want to enforce no space before and a single space after the colon in every declaration:
```css
a { color: pink; }
/** ↑
* No space before and a single space after this colon */
```
You can enforce that with:
```js
"declaration-colon-space-after": "always",
"declaration-colon-space-before": "never"
```
Some *things* (e.g. declaration blocks and value lists) can span more than one line. In these cases `newline` rules and extra options can be used to provide flexibility.
For example, this is the complete set of `value-list-comma-*` rules and their options:
- `value-list-comma-space-after`: `"always"|"never"|"always-single-line"|"never-single-line"`
- `value-list-comma-space-before`: `"always"|"never"|"always-single-line"|"never-single-line"`
- `value-list-comma-newline-after`: `"always"|"always-multi-line|"never-multi-line"`
- `value-list-comma-newline-before`: `"always"|"always-multi-line"|"never-multi-line"`
Where `*-multi-line` and `*-single-line` are in reference to the value list (the *thing*). For example, given:
```css
a,
b {
color: red;
font-family: sans, serif, monospace; /* single line value list */
} ↑ ↑
/** ↑ ↑
* The value list start here and ends here */
```
There is only a single-line value list in this example. The selector is multi-line, as is the declaration block and, as such, also the rule. But the value list isn't and that is what the `*-multi-line` and `*-single-line` refer to in the context of this rule.
#### Example A
Say you only want to allow single-line value lists. And you want to enforce no space before and a single space after the commas:
```css
a {
font-family: sans, serif, monospace;
box-shadow: 1px 1px 1px red, 2px 2px 1px 1px blue inset, 2px 2px 1px 2px blue inset;
}
```
You can enforce that with:
```js
"value-list-comma-space-after": "always",
"value-list-comma-space-before": "never"
```
#### Example B
Say you want to allow both single-line and multi-line value lists. You want there to be a single space after the commas in the single-line lists and no space before the commas in both the single-line and multi-line lists:
```css
a {
font-family: sans, serif, monospace; /* single-line value list with space after, but no space before */
box-shadow: 1px 1px 1px red, /* multi-line value list ... */
2px 2px 1px 1px blue inset, /* ... with newline after, ... */
2px 2px 1px 2px blue inset; /* ... but no space before */
}
```
You can enforce that with:
```js
"value-list-comma-newline-after": "always-multi-line",
"value-list-comma-space-after": "always-single-line",
"value-list-comma-space-before": "never"
```
#### Example C
Say you want to allow both single-line and multi-line value lists. You want there to be no space before the commas in the single-line lists and always a space after the commas in both lists:
```css
a {
font-family: sans, serif, monospace;
box-shadow: 1px 1px 1px red
, 2px 2px 1px 1px blue inset
, 2px 2px 1px 2px blue inset;
}
```
You can enforce that with:
```js
"value-list-comma-newline-before": "always-multi-line",
"value-list-comma-space-after": "always",
"value-list-comma-space-before": "never-single-line"
```
#### Example D
Lastly, the rules are flexible enough to enforce entirely different conventions for single-line and multi-line lists. Say you want to allow both single-line and multi-line value lists. You want the single-line lists to have a single space before and after the colons. Whereas you want the multi-line lists to have a single newline before the commas, but no space after:
```css
a {
font-family: sans , serif , monospace; /* single-line list with a single space before and after the comma */
box-shadow: 1px 1px 1px red /* multi-line list ... */
,2px 2px 1px 1px blue inset /* ... with newline before, ... */
,2px 2px 1px 2px blue inset; /* ... but no space after the comma */
}
```
You can enforce that with:
```js
"value-list-comma-newline-after": "never-multi-line",
"value-list-comma-newline-before": "always-multi-line",
"value-list-comma-space-after": "always-single-line",
"value-list-comma-space-before": "always-single-line"
```
### `*-empty-line-before` and `*-max-empty-lines` rules
These rules work together to control where empty lines are allowed.
Each *thing* is responsible for pushing itself away from the *preceding thing*, rather than pushing the *subsequent thing* away. This consistency is to avoid conflicts, and is why there aren't any `*-empty-line-after` rules in stylelint.
Say you want to enforce the following:
```css
a {
background: green;
color: red;
@media (min-width: 30em) {
color: blue;
}
}
b {
--custom-property: green;
background: pink;
color: red;
}
```
You can do that with:
```js
"at-rule-empty-line-before": ["always", {
"except": ["first-nested"]
}],
"custom-property-empty-line-before": [ "always", {
"except": [
"after-custom-property",
"first-nested"
]
}],
"declaration-empty-line-before": ["always", {
"except": [
"after-declaration",
"first-nested"
]
}],
"block-closing-brace-empty-line-before": "never",
"rule-non-nested-empty-line-before": ["always-multi-line"]
```
We recommend that you set your primary option (e.g. `"always"` or `"never"`) to whatever is your most common occurrence and define your exceptions with the `except` optional secondary options. There are many values for the `except` option e.g. `first-nested`, `after-comment` etc.
The `*-empty-line-before` rules control whether there must never be an empty line or whether there must be *one or more* empty lines before a *thing*. The `*-max-empty-lines` rules complement this by controlling *the number* of empty lines within *things*. The `max-empty-lines` rule is used to set a limit across the entire source. A *stricter* limit can then be set within *things* using the likes of `function-max-empty-lines`, `selector-max-empty-lines` and `value-list-max-empty-lines`.
For example, say you want to enforce the following:
```css
a,
b {
box-shadow:
inset 0 2px 0 #dcffa6,
0 2px 5px #000;
}
c {
transform:
translate(
1,
1
);
}
```
i.e. a maximum of 1 empty line within the whole source, but no empty lines within functions, selector lists and value lists.
You can do that with:
```js
"function-max-empty-lines": 0,
"max-empty-lines": 1,
"selector-list-max-empty-lines": 0,
"value-list-max-empty-lines": 0
```
### `*-whitelist`, `*-blacklist`, `color-named` and applicable `*-no-*` rules
These rules work together to (dis)allow language features and constructs.
There are `*-whitelist` and `*-blacklist` rules that target the main constructs of the CSS language: at-rules, functions, declarations (i.e. property-value pairs), properties and units. These rules can be used to (dis)allow any language features that makes use of these constructs (e.g. `@media`, `rgb()`). However, there are features not caught by these `*-whitelist` and `*-blacklist` rules (or are, but would require complex regex to configure). There are individual rules, usually a `*-no-*` rule (e.g. `color-no-hex` and `selector-no-id`), to disallow each of these features.
Say you want to disallow the `@debug` language extension. You can do that using either the `at-rule-blacklist` or `at-rule-whitelist` rules because the `@debug` language extension uses the at-rule construct e.g.
```js
"at-rule-blacklist": ["debug"]
```
Say you want to, for whatever reason, disallow the whole at-rule construct. You can do that using:
```js
"at-rule-whitelist": []
```
Say you want to disallow the value `none` for the `border` properties. You can do that using either the `declaration-property-value-blacklist` or `declaration-property-value-whitelist` e.g.
```js
"declaration-property-value-blacklist": [{
"/^border/": ["none"]
}]
```
#### color
Most `<color>` values are *functions*. As such, they can be (dis)allowed using either the `function-blacklist` or `function-whitelist` rules. There are two other color representations that aren't functions: named colors and hex colors. There are two specific rules that (dis)allow these: `color-named` and `color-no-hex`, respectively.
Say you want to enforce using a named color *if one exists for your chosen color* and use `hwb` color if one does not, e.g:
```css
a {
background: hwb(235, 0%, 0%); /* there is no named color equivalent for this color */
color: black;
}
```
If you're taking a whitelisting approach, you can do that with:
```js
"color-named": "always-where-possible",
"color-no-hex": true,
"function-whitelist": ["hwb"]
```
Or, if you're taking a blacklisting approach:
```js
"color-named": "always-where-possible",
"color-no-hex": true,
"function-blacklist": ["/^rgb/", "/^hsl/", "gray"]
```
This approach scales to when language extensions (that use the two built-in extendable syntactic constructs of at-rules and functions) are used. For example, say you want to disallow all standard color presentations in favour of using a custom color representation function, e.g. `my-color(red with a dash of green / 5%)`. You can do that with:
```js
"color-named": "never",
"color-no-hex": true,
"function-whitelist": ["my-color"]
```

12
node_modules/stylelint/docs/user-guide/articles.md generated vendored Normal file
View File

@@ -0,0 +1,12 @@
# Articles
A collection of articles and tutorials about stylelint.
- [Lint your CSS with stylelint](https://css-tricks.com/stylelint/): Written by one of stylelint's co-creators, this is the definitive article on stylelint.
- [Stylelint: The Style Sheet Linter We’ve Always Wanted](https://www.smashingmagazine.com/2016/05/stylelint-the-style-sheet-linter-weve-always-wanted/): Why linting a stylesheet matters and how stylelint brings order to a stylesheet. *(We now recommend using [`gulp-stylelint`](https://github.com/olegskl/gulp-stylelint), rather than the `gulp-postcss` and `postcss-reporter` combination outlined in the article. Also, both the “prevent qualified selectors” and “enforce shorthand values” plugins were rolled into the core rules as `selector-no-qualifying-type` and `shorthand-property-no-redundant-values` respectively)*
- [Improving CSS quality at Facebook and beyond](https://code.facebook.com/posts/879890885467584/improving-css-quality-at-facebook-and-beyond): Detailing Facebook's switch from a custom CSS linter to stylelint.
- [How to lint your Sass/CSS properly with Stylelint](http://www.creativenightly.com/2016/02/How-to-lint-your-css-with-stylelint/): Introduction to linting CSS. *(As above, we now recommend using [`gulp-stylelint`](https://github.com/olegskl/gulp-stylelint), rather than the `gulp-postcss` and `postcss-reporter` combination outlined in the article)*
- [Improving the Quality of Your CSS with PostCSS](https://www.sitepoint.com/improving-the-quality-of-your-css-with-postcss/): Introduction to various PostCSS linting tools. *(As above, we recommend using [`gulp-stylelint`](https://github.com/olegskl/gulp-stylelint).)*
- [Floss your style sheets with Stylelint](https://benfrain.com/floss-your-style-sheets-with-stylelint/): The first article written about stylelint. *(As before, we now recommend using [`gulp-stylelint`](https://github.com/olegskl/gulp-stylelint))*
Please send us a Pull Request to add your own article to the list.

68
node_modules/stylelint/docs/user-guide/cli.md generated vendored Normal file
View File

@@ -0,0 +1,68 @@
# The stylelint CLI
## Installation
stylelint is an [npm package](https://www.npmjs.com/package/stylelint). Install it using:
```console
npm install -g stylelint
```
## Usage
`stylelint --help` prints the CLI documentation.
The CLI outputs formatted results into `process.stdout`, which you can read with your human eyes or pipe elsewhere (e.g. write the information to a file).
### Examples
Looking for `.stylelintrc` and linting all `.css` files in the `foo` directory:
```shell
stylelint "foo/*.css"
```
Looking for `.stylelintrc` and linting `stdin`:
```shell
echo "a { color: pink; }" | stylelint
```
Using `bar/mySpecialConfig.json` as config to lint all `.css` files in the `foo` directory, then writing the output to `myTestReport.txt`:
```shell
stylelint "foo/*.css" --config bar/mySpecialConfig.json > myTestReport.txt
```
Using `bar/mySpecialConfig.json` as config, with quiet mode on, to lint all `.css` files in the `foo` directory and any of its subdirectories and also all `.css` files in the `bar directory`, then writing the JSON-formatted output to `myJsonReport.json`:
```shell
stylelint "foo/**/*.css bar/*.css" -q -f json --config bar/mySpecialConfig.json > myJsonReport.json
```
Linting all the `.scss` files in the `foo` directory, using the `syntax` option:
```shell
stylelint "foo/**/*.scss" --syntax scss
```
In addition to `--syntax scss`, stylelint supports `--syntax less` and `--syntax sugarss` by default. If you're using one of the default syntaxes, you may not need to provide a `--syntax` option: non-standard syntaxes can be automatically inferred from the following file extensions: `.less`, `.scss`, and `.sss`.
Additionally, stylelint can accept a custom [PostCSS-compatible syntax](https://github.com/postcss/postcss#syntaxes). To use a custom syntax, supply a syntax module name or path to the syntax file: `--custom-syntax custom-syntax` or `--custom-syntax ./path/to/custom-syntax`.
Note, however, that stylelint can provide no guarantee that core rules will work with syntaxes other than the defaults listed above.
## Syntax errors
The CLI informs you about syntax errors in your CSS.
It uses the same format as it uses for linting warnings.
The error name is `CssSyntaxError`.
## Exit codes
The CLI can exit the process with the following exit codes:
- 1: Something unknown went wrong.
- 2: At least one rule with an "error"-level severity triggered at least one warning.
- 78: There was some problem with the configuration file.
- 80: A file glob was passed, but it found no files.

29
node_modules/stylelint/docs/user-guide/complementary-tools.md generated vendored Normal file
View File

@@ -0,0 +1,29 @@
# Complementary tools
A list of complementary tools built and maintained by the community.
## Analysis platform engines
- [codeclimate-stylelint](https://github.com/gilbarbara/codeclimate-stylelint): Code Climate engine for stylelint
## Autocorrect
- [stylefmt](https://github.com/morishitter/stylefmt): Automatically formats CSS and SCSS source code based on your stylelint configuration.
## Build tool plugins
- [broccoli-stylelint](https://github.com/billybonks/broccoli-stylelint): A Broccoli plugin for stylelint.
- [ember-cli-stylelint](https://github.com/billybonks/ember-cli-stylelint): A Ember CLI plugin for stylelint.
- [grunt-stylelint](https://github.com/wikimedia/grunt-stylelint): A Grunt plugin for stylelint.
- [gulp-stylelint](https://github.com/olegskl/gulp-stylelint): A gulp plugin for stylelint.
- [stylelint-webpack-plugin](https://github.com/vieron/stylelint-webpack-plugin): A webpack plugin for stylelint.
## Editor plugins
- [linter-stylelint](https://github.com/AtomLinter/linter-stylelint): An Atom plugin for stylelint.
- [SublimeLinter-contrib-stylelint](https://github.com/kungfusheep/SublimeLinter-contrib-stylelint): A Sublime Text plugin for stylelint.
- [vscode-stylelint](https://github.com/shinnn/vscode-stylelint): A Visual Studio Code extension for stylelint.
## Editors
- [WebStorm](https://blog.jetbrains.com/webstorm/2016/09/webstorm-2016-3-eap-163-4830-stylelint-usages-for-default-exports-and-more/): Version 2016.3 onwards has built-in support for stylelint.

310
node_modules/stylelint/docs/user-guide/configuration.md generated vendored Normal file
View File

@@ -0,0 +1,310 @@
# Configuration
The linter *expects a configuration object*. You can either craft your own config or extend an existing one.
## Loading the configuration object
Finding and loading of your configuration object is done with [cosmiconfig](https://github.com/davidtheclark/cosmiconfig). Starting from the current working directory, it will look for the following possible sources, in this order:
- a `stylelint` property in `package.json`
- a `.stylelintrc` file
- a `stylelint.config.js` file exporting a JS object
The `.stylelintrc` file (without extension) can be in JSON or YAML format. Alternately, you can add a filename extension to designate JSON, YAML, or JS format: `.stylelintrc.json`, `.stylelintrc.yaml`, `.stylelintrc.js`. You may want to use an extension so that your text editor can better interpret the file, and help with syntax checking and highlighting.
Once one of these is found and parsed, the search will stop and that object will be used.
The configuration search can be short-circuited by using either the `config` or `configFile` options.
## The configuration object
The configuration object can have the following properties.
### `rules`
Rules determine what the linter looks for and complains about. There are [over 150](rules.md) built into stylelint. *No rules are turned on by default*, so this is where you turn on everything you want to check. All the rules must be explicitly configured as *there are no default values*.
The `rules` property is *an object whose keys are rule names and values are rule configurations*. Each rule configuration fits one of the following formats:
- a single value (the primary option)
- an array with two values (`[primary option, secondary options]`)
- `null` (to turn the rule off)
```json
{
"rules": {
"block-no-empty": null,
"color-no-invalid-hex": true,
"comment-empty-line-before": [ "always", {
"ignore": ["stylelint-command", "after-comment"]
} ],
"declaration-colon-space-after": "always",
"indentation": ["tab", {
"except": ["value"]
}],
"max-empty-lines": 2,
"rule-nested-empty-line-before": [ "always", {
"except": ["first-nested"],
"ignore": ["after-comment"]
} ],
"unit-whitelist": ["em", "rem", "%", "s"]
}
}
```
Specifying a primary option will turn a rule on. A complete list of primary rule options can be found in the [example configuration](example-config.md).
To turn a rule off (when extending a configuration) you can set the value of the rule to `null`:
```json
{
"extends": "stylelint-config-standard",
"rules": {
"at-rule-empty-line-before": null
}
}
```
Many rules have secondary options which provide further customization. To set secondary options, a two-member array is used:
```js
"selector-pseudo-class-no-unknown": [true, {
"ignorePseudoClasses": ["global"]
}]
```
#### Turning rules off from within your CSS
Rules can be temporarily turned off by using special comments in your CSS. For example, you can either turn all the rules off:
```css
/* stylelint-disable */
a {}
/* stylelint-enable */
```
Or you can turn off individual rules:
```css
/* stylelint-disable selector-no-id, declaration-no-important */
#id {
color: pink !important;
}
/* stylelint-enable */
```
You can turn off rules for individual lines only with a `/* stylelint-disable-line */` comment, after which you do not need to explicitly re-enable them:
```css
#id { /* stylelint-disable-line */
color: pink !important; /* stylelint-disable-line declaration-no-important */
}
```
You can also turn off rules for *the next line only* with a `/* stylelint-disable-next-line */` comment, after which you do not need to explicitly re-enable them:
```css
#id {
/* stylelint-disable-next-line declaration-no-important */
color: pink !important;
}
```
Complex, overlapping disabling & enabling patterns are supported:
```css
/* stylelint-disable */
/* stylelint-enable foo */
/* stylelint-disable foo */
/* stylelint-enable */
/* stylelint-disable foo, bar */
/* stylelint-disable baz */
/* stylelint-enable baz, bar */
/* stylelint-enable foo */
```
**Caveat:** Comments within *selector and value lists* are currently ignored.
#### Severities: error & warning
By default, all rules have an `"error"`-level severity. You can change this default by adding a `defaultSeverity` property to your configuration (see below).
To adjust any specific rule's severity, use the secondary option `severity`. The available values for `severity` are:
- `"warning"`
- `"error"`
```js
// error-level severity examples
{ "indentation": 2 }
{ "indentation": [2] }
// warning-level severity examples
{ "indentation": [2, { "severity": "warning" } ] }
{ "indentation": [2, {
"except": ["value"],
"severity": "warning"
}]
}
```
Different reporters may use these severity levels in different way, e.g. display them differently, or exit the process differently.
#### Custom Messages
If you want to deliver a custom message when a rule is violated, you can do so in two ways: provide a `message` option for the rule, or write a custom formatter.
All rules accept a `message` secondary option that, if provided, will be substituted for whatever standard message would be provided. For example, the following rule configuration would substitute in a couple of custom message:
```json
{
"color-hex-case": [ "lower", {
"message": "Lowercase letters are easier to distinguish from numbers"
} ],
"indentation": [ 2, {
"ignore": ["block"],
"message": "Please use 2 spaces for indentation. Tabs make The Architect grumpy.",
"severity": "warning"
} ]
}
```
Writing a [custom formatter](../developer-guide/formatters.md) gives you maximum control if you need serious customization.
### `extends`
Your configuration can *extend* an existing configuration (whether your own or a third-party config). When one configuration extends another, it starts with the other's properties then adds to and overrides what's there.
You can extend an array of existing configurations, with each item in the array taking precedence over the following (so the first item overrides everything else, the second item overrides everything but the first, the last gets overridden by everything else, etc.).
For example, extending the [`stylelint-config-standard`](https://github.com/stylelint/stylelint-config-standard) and then changing indentation to tabs and turning off the `number-leading-zero` rule:
```json
{
"extends": "stylelint-config-standard",
"rules": {
"indentation": "tab",
"number-leading-zero": null
}
}
```
Or starting with `stylelint-config-standard`, then layering `myExtendableConfig` on top of that, and then overriding the indentation rule:
```json
{
"extends": [
"stylelint-config-standard",
"./myExtendableConfig"
],
"rules": {
"indentation": "tab"
}
}
```
The value of `"extends"` is a "locater" (or an array of "locaters") that is ultimately `require()`d, so can fit whatever format works with Node's `require.resolve()` algorithm. That means the a "locater" can be:
- The name of a module in `node_modules` (e.g. `stylelint-config-standard`; that module's `main` file must be a valid JSON configuration)
- An absolute path to a file (which makes sense if you're creating a JS object in a Node context and passing it in) with a `.js` or `.json` extension.
- A relative path to a file with a `.js` or `.json` extension, relative to the referencing configuration (e.g. if configA has `extends: "../configB"`, we'll look for `configB` relative to configA).
*Because of `extends`, you can create and use shareable stylelint configurations.* Use the `stylelint-config` keyword within your `package.json` if publishing your config to npm.
### `plugins`
Plugins are rules or sets of rules built by the community that support methodologies, toolsets, *non-standard* CSS features, or very specific use cases.
To use one, add a `"plugins"` array to your config, containing "locaters" identifying the plugins you want to use. As with `extends`, above, a "locater" can be either an npm module name, an absolute path, or a path relative to the invoking configuration file.
Once the plugin is declared, within your `"rules"` object *you'll need to add options* for the plugin's rule(s), just like any standard rule. You will have to look at the plugin's documentation to know what the rule name should be.
```json
{
"plugins": [
"../special-rule.js"
],
"rules": {
"plugin/special-rule": "everything"
}
}
```
A "plugin" can provide a single rule or a set of rules. If the plugin you use provides a set, just invoke the module in your `"plugins"` configuration value, and use the rules it provides in `"rules"`. For example:
```json
{
"plugins": [
"../some-rule-set.js"
],
"rules": {
"some-rule-set/first-rule": "everything",
"some-rule-set/second-rule": "nothing",
"some-rule-set/third-rule": "everything"
}
}
```
### `processors`
Processors are functions that hook into stylelint's pipeline, modifying code on its way into stylelint and modifying results on their way out.
*Processors can only be used with the CLI and the Node API, not with the PostCSS plugin.* (The PostCSS plugin will ignore them.)
Processors can enable stylelint to lint the CSS within non-stylesheet files. For example, you could lint the CSS within `<style>` tags in HTML, code blocks in Markdown, or strings in JavaScript.
To use one, add a `"processors"` array to your config, containing "locaters" identifying the processors you want to use. As with `extends`, above, a "locater" can be either an npm module name, an absolute path, or a path relative to the invoking configuration file.
```json
{
"processors": ["stylelint-html-processor"],
"rules": {..}
}
```
If your processor has options, make that item an array whose first item is the "locator" and second item is the options object.
```json
{
"processors": [
"stylelint-html-processor",
[ "some-other-processor", { "optionOne": true, "optionTwo": false } ]
],
"rules": {..}
}
```
### `ignoreFiles`
Provide a glob or array of globs to ignore specific files.
(An alternative method is to use a `.stylelintignore` file, described below.)
If the globs are absolute paths, they are used as is. If they are relative, they are analyzed relative to
- `configBasedir`, if it's provided;
- the config's filepath, if the config is a file that stylelint found a loaded;
- or `process.cwd()`.
`node_modules` and `bower_components` are always ignored.
The `ignoreFiles` property is stripped from extended configs: only the root-level config can ignore files.
### `defaultSeverity`
The default severity level for all rules that do not have a severity specified in their secondary options. The available values for `severity` are:
- `"warning"`
- `"error"`
## `.stylelintignore`
You can use a `.stylelintignore` file (or point to another ignore patterns file) to ignore specific files.
(An alternative method is to use a `config.ignoreFiles`, described above.)
The patterns in your `.stylelintignore` file must match [`.gitignore` syntax](https://git-scm.com/docs/gitignore). (Behind the scenes, [`node-ignore`](https://github.com/kaelzhang/node-ignore) parses your patterns.) One implication of this is that *your patterns in `.stylelintignore` are always analyzed relative to `process.cwd()`.*
stylelint will look for a `.stylelintignore` file in `process.cwd()`. You can also specify a path to your ignore patterns file (absolute or relative to `process.cwd()`) using the `--ignore-path` (in the CLI) and `ignorePath` (in JS) options.
`node_modules` and `bower_components` are always ignored.

46
node_modules/stylelint/docs/user-guide/css-processors.md generated vendored Normal file
View File

@@ -0,0 +1,46 @@
# 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 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.
## Parsing non-standard syntax
By default, the linter can *parse* any the following non-standard syntaxes by using special PostCSS parsers:
- SCSS (using [`postcss-scss`](https://github.com/postcss/postcss-scss))
- Less (using [`postcss-less`](https://github.com/webschik/postcss-less))
- SugarSS (using [`sugarss`](https://github.com/postcss/sugarss))
*Non-standard syntaxes can automatically be inferred from the following file extensions: `.less`, `.scss`, and `.sss`.* If you would need to specify your non-standard syntax, though, both the [CLI](cli.md) and the [Node 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 API, pass in the `syntax` option like so: `stylelint.lint({ syntax: "sugarss", ... })`.
Additionally, stylelint can accept a custom [PostCSS-compatible syntax](https://github.com/postcss/postcss#syntaxes) when using the CLI or Node API. For custom syntaxes, please 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 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'll need to use the special parser directly with PostCSS's `syntax` option like so:
```js
var postcss = require("postcss")
var scss = require("postcss-scss")
// or use "postcss-less" or "sugarss"
postcss([
require("stylelint"),
require("reporter")
])
.process(css, {
from: "lib/app.css",
syntax: scss
})
})
```

171
node_modules/stylelint/docs/user-guide/example-config.md generated vendored Normal file
View File

@@ -0,0 +1,171 @@
# Example config
This example config lists all of the [rules](rules.md) and their primary options. You can remove ([or turn off](configuration.md#rules)) the rules you don't want and edit the primary option of each rule to your liking.
You might want to learn a little about [how rules are named and how they work together](about-rules.md), to get a better idea of what each rule does.
```json
{
"rules": {
"at-rule-blacklist": string|[],
"at-rule-empty-line-before": "always"|"never",
"at-rule-name-case": "lower"|"upper",
"at-rule-name-newline-after": "always"|"always-multi-line",
"at-rule-name-space-after": "always"|"always-single-line",
"at-rule-no-unknown": true,
"at-rule-no-vendor-prefix": true,
"at-rule-semicolon-newline-after": "always",
"at-rule-whitelist": string|[],
"block-closing-brace-empty-line-before": "always-multi-line"|"never",
"block-closing-brace-newline-after": "always"|"always-single-line"|"never-single-line"|"always-multi-line"|"never-multi-line",
"block-closing-brace-newline-before": "always"|"always-multi-line"|"never-multi-line",
"block-closing-brace-space-after": "always"|"always-single-line"|"never-single-line"|"always-multi-line"|"never-multi-line",
"block-closing-brace-space-before": "always"|"never"|"always-single-line"|"never-single-line"|"always-multi-line"|"never-multi-line",
"block-no-empty": true,
"block-opening-brace-newline-after": "always"|"always-multi-line"|"never-multi-line",
"block-opening-brace-newline-before": "always"|"always-single-line"|"never-single-line"|"always-multi-line"|"never-multi-line",
"block-opening-brace-space-after": "always"|"always-single-line"|"never-single-line"|"always-multi-line"|"never-multi-line",
"block-opening-brace-space-before": "always"|"always-single-line"|"never-single-line"|"always-multi-line"|"never-multi-line",
"color-hex-case": "lower"|"upper",
"color-hex-length": "short"|"long",
"color-named": "always-where-possible"|"never",
"color-no-hex": true,
"color-no-invalid-hex": true,
"comment-empty-line-before": "always"|"never",
"comment-no-empty": true,
"comment-whitespace-inside": "always"|"never",
"comment-word-blacklist": string|[],
"custom-media-pattern": string,
"custom-property-empty-line-before": "always"|"never",
"custom-property-pattern": string,
"declaration-bang-space-after": "always"|"never",
"declaration-bang-space-before": "always"|"never",
"declaration-block-no-duplicate-properties": true,
"declaration-block-no-redundant-longhand-properties": true,
"declaration-block-no-shorthand-property-overrides": true,
"declaration-block-semicolon-newline-after": "always"|"always-multi-line"|"never-multi-line",
"declaration-block-semicolon-newline-before": "always"|"always-multi-line"|"never-multi-line",
"declaration-block-semicolon-space-after": "always"|"never"|"always-single-line"|"never-single-line",
"declaration-block-semicolon-space-before": "always"|"never"|"always-single-line"|"never-single-line",
"declaration-block-single-line-max-declarations": int,
"declaration-block-trailing-semicolon": "always"|"never",
"declaration-colon-newline-after": "always"|"always-multi-line",
"declaration-colon-space-after": "always"|"never"|"always-single-line",
"declaration-colon-space-before": "always"|"never",
"declaration-empty-line-before": "always"|"never",
"declaration-no-important": true,
"declaration-property-unit-blacklist": {},
"declaration-property-unit-whitelist": {},
"declaration-property-value-blacklist": {},
"declaration-property-value-whitelist": {},
"font-family-name-quotes": "always-where-required"|"always-where-recommended"|"always-unless-keyword",
"font-family-no-duplicate-names": true,
"font-weight-notation": "numeric"|"named",
"function-blacklist": string|[],
"function-calc-no-unspaced-operator": true,
"function-comma-newline-after": "always"|"always-multi-line"|"never-multi-line",
"function-comma-newline-before": "always"|"always-multi-line"|"never-multi-line",
"function-comma-space-after": "always"|"never"|"always-single-line"|"never-single-line",
"function-comma-space-before": "always"|"never"|"always-single-line"|"never-single-line",
"function-linear-gradient-no-nonstandard-direction": true,
"function-max-empty-lines": int,
"function-name-case": "lower"|"upper",
"function-parentheses-newline-inside": "always"|"always-multi-line"|"never-multi-line",
"function-parentheses-space-inside": "always"|"never"|"always-single-line"|"never-single-line",
"function-url-data-uris": "always"|"never",
"function-url-no-scheme-relative": true,
"function-url-quotes": "always"|"never",
"function-url-scheme-whitelist": string|[],
"function-whitelist": string|[],
"function-whitespace-after": "always"|"never",
"indentation": int|"tab",
"keyframe-declaration-no-important": true,
"length-zero-no-unit": true,
"max-empty-lines": int,
"max-line-length": int,
"max-nesting-depth": int,
"media-feature-colon-space-after": "always"|"never",
"media-feature-colon-space-before": "always"|"never",
"media-feature-name-blacklist": string|[],
"media-feature-name-case": "lower"|"upper",
"media-feature-name-no-unknown": true,
"media-feature-name-no-vendor-prefix": true,
"media-feature-name-whitelist": string|[],
"media-feature-parentheses-space-inside": "always"|"never",
"media-feature-range-operator-space-after": "always"|"never",
"media-feature-range-operator-space-before": "always"|"never",
"media-query-list-comma-newline-after": "always"|"always-multi-line"|"never-multi-line",
"media-query-list-comma-newline-before": "always"|"always-multi-line"|"never-multi-line",
"media-query-list-comma-space-after": "always"|"never"|"always-single-line"|"never-single-line",
"media-query-list-comma-space-before": "always"|"never"|"always-single-line"|"never-single-line",
"no-descending-specificity": true,
"no-duplicate-selectors": true,
"no-empty-source": true,
"no-eol-whitespace": true,
"no-extra-semicolons": true,
"no-invalid-double-slash-comments": true,
"no-missing-end-of-source-newline": true,
"no-unknown-animations": true,
"number-leading-zero": "always"|"never",
"number-max-precision": int,
"number-no-trailing-zeros": true,
"property-blacklist": string|[],
"property-case": "lower"|"upper",
"property-no-unknown": true,
"property-no-vendor-prefix": true,
"property-whitelist": string|[],
"rule-empty-line-before": "always"|"never"|"always-multi-line"|"never-multi-line",
"selector-attribute-brackets-space-inside": "always"|"never",
"selector-attribute-operator-blacklist": string|[],
"selector-attribute-operator-space-after": "always"|"never",
"selector-attribute-operator-space-before": "always"|"never",
"selector-attribute-operator-whitelist": string|[],
"selector-attribute-quotes": "always"|"never",
"selector-class-pattern": string,
"selector-combinator-space-after": "always"|"never",
"selector-combinator-space-before": "always"|"never",
"selector-descendant-combinator-no-non-space": true,
"selector-id-pattern": string,
"selector-list-comma-newline-after": "always"|"always-multi-line"|"never-multi-line",
"selector-list-comma-newline-before": "always"|"always-multi-line"|"never-multi-line",
"selector-list-comma-space-after": "always"|"never"|"always-single-line"|"never-single-line",
"selector-list-comma-space-before": "always"|"never"|"always-single-line"|"never-single-line",
"selector-max-empty-lines": int,
"selector-max-compound-selectors": int,
"selector-max-specificity": string,
"selector-nested-pattern": string,
"selector-no-attribute": true,
"selector-no-combinator": true,
"selector-no-id": true,
"selector-no-qualifying-type": true,
"selector-no-type": true,
"selector-no-universal": true,
"selector-no-vendor-prefix": true,
"selector-pseudo-class-blacklist": string|[],
"selector-pseudo-class-case": "lower"|"upper",
"selector-pseudo-class-no-unknown": true,
"selector-pseudo-class-parentheses-space-inside": "always"|"never",
"selector-pseudo-class-whitelist": string|[],
"selector-pseudo-element-case": "lower"|"upper",
"selector-pseudo-element-colon-notation": "single"|"double",
"selector-pseudo-element-no-unknown": true,
"selector-type-case": "lower"|"upper",
"selector-type-no-unknown": true,
"shorthand-property-no-redundant-values": true,
"string-no-newline": true,
"string-quotes": "single"|"double",
"time-min-milliseconds": int,
"unit-blacklist": string|[],
"unit-case": "lower"|"upper",
"unit-no-unknown": true,
"unit-whitelist": string|[],
"value-keyword-case": "lower"|"upper",
"value-list-comma-newline-after": "always"|"always-multi-line"|"never-multi-line",
"value-list-comma-newline-before": "always"|"always-multi-line"|"never-multi-line",
"value-list-comma-space-after": "always"|"never"|"always-single-line"|"never-single-line",
"value-list-comma-space-before": "always"|"never"|"always-single-line"|"never-single-line",
"value-list-max-empty-lines": int,
"value-no-vendor-prefix": true
}
}
```

163
node_modules/stylelint/docs/user-guide/faq.md generated vendored Normal file
View File

@@ -0,0 +1,163 @@
# FAQ
## How do I disable a rule?
You can disable a rule by setting its config value to `null`.
For example, to use `stylelint-config-standard` without the `at-rule-empty-line-before` rule:
```json
{
"extends": "stylelint-config-standard",
"rules": {
"at-rule-empty-line-before": null
}
}
```
You can also disable a rule for specific sections of your CSS. Refer to the rules section of the [configuration guide](configuration.md#rules) for more information.
## How do I lint from the command line?
Refer to the [CLI section](cli.md) of the docs.
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.
## How do I lint using Git pre-commit hooks?
[lint-staged](https://github.com/okonet/lint-staged) is a NodeJS script that supports running stylelint against Git staged files.
## How do I lint using my task runner of choice?
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.
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.
There are also examples of using the PostCSS plugin via the PostCSS JS API within the [docs](postcss-plugin.md).
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.
## How do I lint within my text editor?
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.
## How do I lint SCSS, Less, or other non-standard syntax?
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.
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.
Refer to the [docs](css-processors.md#parsing-non-standard-syntax) on how to configure stylelint to parse non-standard syntaxes.
## Should I lint before or after processing my stylesheets through PostCSS plugins or other processors?
We [recommend](css-processors.md) linting your source files before any transformations.
## How do I lint styles within `<style>` tags?
[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.
## How do I automatically fix stylistic warnings?
[stylefmt](https://github.com/morishitter/stylefmt) supports stylelint configuration files and can automatically fix a number of stylistic warnings.
## How do I manage conflicts between rules?
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`.
It's your responsibility as the configuration author to resolve these conflicts.
## What is the difference between a plugin and a rule?
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.
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.
Plugins are easy to incorporate into your configuration.
## Can I customise stylelint's messages?
Yes, you can either use the [`message` secondary option](configuration.md#custom-messages) or [write your own formatter](../developer-guide/formatters.md).
## How should I lint my CSS that follows a BEM-like methodology?
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.
You can also take advantage of the `selector-*` rules to ban certain types of selectors (e.g. id selectors) and control specificity.
If you're using SUITCSS, you might want to use [their shareable config](https://github.com/suitcss/stylelint-config-suitcss).
## How do I disallow single-line blocks?
```css
a { color: red; }
/** ↑
* Declaration blocks like this */
```
Use the `block-opening-brace-newline-after` and `block-opening-brace-newline-before` rules together. For example, this config:
```json
{
"block-opening-brace-newline-after": ["always"],
"block-closing-brace-newline-before": ["always"]
}
```
Would allow:
```css
a {
color: red;
}
```
But not these patterns:
```css
a { color: red;
}
a {
color: red; }
a { color: red; }
```
To allow single-line blocks but enforce newlines with multi-line blocks, use the `"always-multi-line"` option for both rules.
## How do I configure the `*-pattern` rules for common CSS naming conventions like kebab-case?
Use the regex that corresponds to your chosen convention:
- kebab-case: `^([a-z][a-z0-9]*)(-[a-z0-9]+)*$`
- lowerCamelCase: `^[a-z][a-zA-Z0-9]+$`
- snake\_case: `^([a-z][a-z0-9]*)(_[a-z0-9]+)*$`
- UpperCamelCase: `^[A-Z][a-zA-Z0-9]+$`
e.g. for lowerCamelCase class selectors, use `"selector-class-pattern": "^[a-z][a-zA-Z0-9]+$"`.
All these patterns disallow CSS identifiers that start with a digit, two hyphens, or a hyphen followed by a digit.
## How do I change the default severity to "warning" so stylelint doesn't break my build?
Use the [`defaultSeverity`](configuration.md#defaultseverity) configuration option.
## Can I bundle more than one sharable config within a npm package?
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')`).
## How can I control the whitespace after the open brace of the block?
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.
## If I use `extends` within my configuration object, will the options for each rule be merged or overridden?
They will be overridden.
The `extends` mechanism is [detailed within the configuration docs](configuration.md#extends):
> When one configuration extends another, it starts with the other's properties then adds to and overrides what's there.
The reason for this design is documented in [#1646](https://github.com/stylelint/stylelint/issues/1646#issuecomment-232779957).

184
node_modules/stylelint/docs/user-guide/node-api.md generated vendored Normal file
View File

@@ -0,0 +1,184 @@
# The stylelint Node API
The stylelint module includes a `lint()` function that provides the Node API.
```js
stylelint.lint(options)
.then(function(resultObject) { .. });
```
## Installation
stylelint is an [npm package](https://www.npmjs.com/package/stylelint). Install it using:
```console
npm install stylelint
```
## Options
Options is an object with the following properties.
Though both `files` and `code` are "optional", you *must* have one and *cannot* have both. All other options are optional.
### `code`
A CSS string to be linted.
### `codeFilename`
If using `code` to pass a source string directly, you can use `codeFilename` to associate that code with a particular filename.
This can be useful, for example, when making a text editor plugin that passes in code directly but needs to still use the configuration's `ignoreFiles` functionality to possibly ignore that code.
### `config`
A [stylelint configuration object](configuration.md).
If no `config` or `configFile` is passed, stylelint will look for a `.stylelintrc` configuration file.
### `configBasedir`
An absolute path to the directory that relative paths defining `extends` and `plugins` are *relative to*.
If the `config` object passed uses relative paths, e.g. for `extends` or `plugins`, you are going to have to pass a `configBasedir`. If not, you do not need this.
### `configFile`
The path to a JSON, YAML, or JS file that contains your [stylelint configuration object](configuration.md).
It should be either absolute or relative to the directory that your process is running from (`process.cwd()`). We'd recommend absolute.
### `configOverrides`
A partial stylelint configuration object whose properties will override the existing config object, whether that config was loaded via the `config` option or a `.stylelintrc` file.
The difference between the `configOverrides` and `config` options is this: If any `config` object is passed, stylelint does not bother looking for a `.stylelintrc` file and instead just uses whatever `config` object you've passed; but if you want to *both* load a `.stylelintrc` file *and* override specific parts of it, `configOverrides` does just that.
### `files`
A file glob, or array of file globs. Ultimately passed to [node-glob](https://github.com/isaacs/node-glob) to figure out what files you want to lint.
Relative globs are considered relative to `process.cwd()`.
`node_modules` and `bower_components` are always ignored.
### `formatter`
Options: `"json"|"string"|"verbose"`, or a function. Default is `"json"`.
Specify the formatter that you would like to use to format your results.
If you pass a function, it must fit the signature described in the [Developer Guide](../developer-guide/formatters.md).
### `ignoreDisables`
If `true`, all disable comments (e.g. `/* stylelint-disable block-no-empty */`) will be ignored.
You can use this option to see what your linting results would be like without those exceptions.
### `reportNeedlessDisables`
If `true`, `ignoreDisables` will also be set to `true` and the returned data will contain a `needlessDisables` property, whose value is an array of objects, one for each source, with tells you which stylelint-disable comments are not blocking a lint warning.
Use this report to clean up your codebase, keeping only the stylelint-disable comments that serve a purpose.
*The recommended way to use this option is through the CLI.* It will output a clean report to the console.
### `ignorePath`
A path to a file containing patterns describing files to ignore. The path can be absolute or relative to `process.cwd()`. By default, stylelint looks for `.stylelintignore` in `process.cwd()`. See [Configuration](configuration.md#stylelintignore).
### `syntax`
Options: `"scss"|"less"|"sugarss"`
Specify a non-standard syntax that should be used to parse source stylesheets.
If you do not specify a syntax, non-standard syntaxes will be automatically inferred by the file extensions `.scss`, `.less`, and `.sss`.
See the [`customSyntax`](#customsyntax) option below if you would like to use stylelint with a custom syntax.
### `customSyntax`
An absolute path to a custom [PostCSS-compatible syntax](https://github.com/postcss/postcss#syntaxes) module.
Note, however, that stylelint can provide no guarantee that core rules will work with syntaxes other than the defaults listed for the `syntax` option above.
## The returned promise
`stylelint.lint()` returns a Promise that resolves with an object containing the following properties:
### `errored`
Boolean. If `true`, at least one rule with an "error"-level severity registered a warning.
### `output`
A string displaying the formatted warnings (using the default formatter or whichever you passed).
### `postcssResults`
An array containing all the [PostCSS LazyResults](https://github.com/postcss/postcss/blob/master/docs/api.md#lazyresult-class) that were accumulated during processing.
### `results`
An array containing all the stylelint result objects (the objects that formatters consume).
## Syntax errors
`stylelint.lint()` does not reject the Promise when your CSS contains syntax errors.
It resolves with an object (see [The returned promise](#the-returned-promise)) that contains information about the syntax error.
## Usage examples
If `myConfig` contains no relative paths for `extends` or `plugins`, you do not have to use `configBasedir`:
```js
stylelint.lint({
config: myConfig,
files: "all/my/stylesheets/*.css"
})
.then(function(data) {
// do things with data.output, data.errored,
// and data.results
})
.catch(function(err) {
// do things with err e.g.
console.error(err.stack);
});;
```
If `myConfig` *does* contain relative paths for `extends` or `plugins`, you *do* have to use `configBasedir`:
```js
stylelint.lint({
config: myConfig,
configBasedir: path.join(__dirname, "configs"),
files: "all/my/stylesheets/*.css"
}).then(function() { .. });
```
Maybe you want to use a CSS string instead of a file glob, and you want to use the string formatter instead of the default JSON:
```js
stylelint.lint({
code: "a { color: pink; }",
config: myConfig,
formatter: "string"
}).then(function() { .. });
```
Maybe you want to use my own custom formatter function and parse `.scss` source files:
```js
stylelint.lint({
config: myConfig,
files: "all/my/stylesheets/*.scss",
formatter: function(stylelintResults) { .. },
syntax: "scss"
}).then(function() { .. });
```
The same pattern can be used to read Less or [SugarSS](https://github.com/postcss/sugarss) syntax.

12
node_modules/stylelint/docs/user-guide/plugins.md generated vendored Normal file
View File

@@ -0,0 +1,12 @@
# Plugins
Plugins are rules and sets of rules built by the community that support methodologies, toolsets, *non-standard* CSS features, or very specific use cases. Their *package* names are prefixed with "stylelint". Their *rule* names are namespaced so that they do not clash with stylelint's core rules.
- [`stylelint-csstree-validator`](https://github.com/csstree/stylelint-validator): Validate CSS values to match W3C specs and browsers extensions.
- [`stylelint-declaration-strict-value`](https://github.com/AndyOGo/stylelint-declaration-strict-value): Specify properties for which either a variable (`$sass`, `@less`, `var(--cssnext)`), function or custom CSS keyword (`inherit`, `none`, etc.) must be used for its value.
- [`stylelint-declaration-use-variable`](https://github.com/sh-waqar/stylelint-declaration-use-variable): Specify properties for which a variable must be used for its value.
- [`stylelint-no-browser-hacks`](https://github.com/Slamdunk/stylelint-no-browser-hacks): Disallow browser hacks that are irrelevant to the browsers you are targeting; uses [stylehacks](https://github.com/ben-eb/stylehacks).
- [`stylelint-order`](https://github.com/hudochenkov/stylelint-order): Specify the ordering of things e.g. properties within declaration blocks (plugin pack).
- [`stylelint-rscss`](https://github.com/rstacruz/stylelint-rscss): Validate [RSCSS](http://rscss.io) conventions.
- [`stylelint-scss`](https://github.com/kristerkari/stylelint-scss): Enforce a wide variety of SCSS-syntax specific linting rules (plugin pack).
- [`stylelint-selector-bem-pattern`](https://github.com/davidtheclark/stylelint-selector-bem-pattern): Specify a BEM pattern for selectors (incorporates [postcss-bem-linter](https://github.com/postcss/postcss-bem-linter)).

123
node_modules/stylelint/docs/user-guide/postcss-plugin.md generated vendored Normal file
View File

@@ -0,0 +1,123 @@
# The stylelint PostCSS plugin
As with any other [PostCSS plugin](https://github.com/postcss/postcss#plugins), you can use stylelint's PostCSS plugin either with a PostCSS runner or with the PostCSS JS API directly.
*However, if a dedicated stylelint task runner plugin [is available](complementary-tools.md) (e.g. [gulp-stylelint](https://github.com/olegskl/gulp-stylelint) or [grunt-stylelint](https://github.com/wikimedia/grunt-stylelint)) we recommend you use that rather than this plugin, as they provide better reporting.*
## Installation
stylelint is an [npm package](https://www.npmjs.com/package/stylelint). Install it using:
```console
npm install stylelint
```
## Options
The plugin accepts an options object as argument, with the following properties:
### `config`
A [stylelint configuration object](configuration.md).
If no `config` or `configFile` is passed, stylelint will look for a `.stylelintrc` configuration file.
### `configFile`
The path to a JSON, YAML, or JS file that contains your [stylelint configuration object](configuration.md).
It should be either absolute or relative to the directory that your process is running from (`process.cwd()`). We'd recommend absolute.
### `configBasedir`
An absolute path to the directory that relative paths defining `extends` and `plugins` are *relative to*.
This is only necessary if you passed an object directly through the `config` property. If you used
`configFile`, this option is not necessary.
If the `config` object passed uses relative paths, e.g. for `extends` or `plugins`, you are going to have to pass a `configBasedir`. If not, you do not need this.
### `configOverrides`
A partial stylelint configuration object whose properties will override the existing config object, whether that config was loaded via the `config` option or a `.stylelintrc` file.
The difference between the `configOverrides` and `config` options is this: If any `config` object is passed, stylelint does not bother looking for a `.stylelintrc` file and instead just uses whatever `config` object you've passed; but if you want to *both* load a `.stylelintrc` file *and* override specific parts of it, `configOverrides` does just that.
### `ignoreDisables`
If `true`, all disable comments (e.g. `/* stylelint-disable block-no-empty */`) will be ignored.
You can use this option to see what your linting results would be like without those exceptions.
### `ignorePath`
A path to a file containing patterns describing files to ignore. The path can be absolute or relative to `process.cwd()`. By default, stylelint looks for `.stylelintignore` in `process.cwd()`. See [Configuration](configuration.md#stylelintignore).
## Usage examples
We recommend you lint your CSS before applying any transformations. You can do this by either:
- creating a separate lint task that is independent of your build one.
- using the [`plugins` option](https://github.com/postcss/postcss-import#plugins) of [`postcss-import`](https://github.com/postcss/postcss-import) or [`postcss-easy-import`](https://github.com/TrySound/postcss-easy-import) to lint the your files before any transformations.
- placing stylelint at the beginning of your plugin pipeline.
You'll also need to use a reporter. *The stylelint plugin registers warnings via PostCSS*. Therefore, you'll want to use it with a PostCSS runner that prints warnings or another PostCSS plugin whose purpose is to format and print warnings (e.g. [`postcss-reporter`](https://github.com/postcss/postcss-reporter)).
### Example A
A separate lint task that uses the plugin via the PostCSS JS API to lint Less using [`postcss-less`](https://github.com/webschik/postcss-less).
*Note: the stylelint PostCSS plugin, unlike the stylelint CLI and node API, doesn't have a `syntax` option. Instead, the syntax must be set within the [PostCSS options](https://github.com/postcss/postcss#options) as there can only be one parser/syntax in a pipeline.*
```js
var fs = require("fs")
var less = require("postcss-less")
var postcss = require("postcss")
// CSS to be processed
var css = fs.readFileSync("input.css", "utf8")
postcss([
require("stylelint")({ /* your options */ })
require("postcss-reporter")({ clearMessages: true })
])
.process(css, {
from: "input.css",
syntax: less
})
.then()
.catch(err => console.error(err.stack))
```
The same pattern can be used to lint SCSS or [SugarSS](https://github.com/postcss/sugarss) syntax.
### Example B
A combined lint and build task where the plugin is used via the PostCSS JS API, but within [`postcss-import`](https://github.com/postcss/postcss-import) (using the its `plugins` option) so that the source files are linted before any transformations.
```js
var fs = require("fs")
var postcss = require("postcss")
var stylelint = require("stylelint")
// CSS to be processed
var css = fs.readFileSync("lib/app.css", "utf8")
postcss(
processors: [
require("postcss-import")({
plugins: [
require("stylelint")({ /* your options */ })
]
}),
require("postcss-cssnext")
require("postcss-reporter")({ clearMessages: true })
]
)
.process(css, { from: 'lib/app.css', to: 'app.css' })
.then(function (result) {
fs.writeFileSync('app.css', result.css);
if ( result.map ) fs.writeFileSync('app.css.map', result.map);
})
.catch(err => console.error(err.stack))
```

9
node_modules/stylelint/docs/user-guide/processors.md generated vendored Normal file
View File

@@ -0,0 +1,9 @@
# Processors
Processors are community packages that enable stylelint to lint the CSS within non-stylesheet files. For example, you could lint the CSS within `<style>` tags in HTML, code blocks in Markdown, or strings in JavaScript.
*Processors can only be used with the CLI and the Node API, not with the PostCSS plugin.* (The PostCSS plugin will ignore them.)
- [stylelint-processor-arbitrary-tags](https://github.com/mapbox/stylelint-processor-arbitrary-tags): Lint within user-specified tags.
- [stylelint-processor-html](https://github.com/ccbikai/stylelint-processor-html): Lint within HTML `<style>` tags.
- [stylelint-processor-markdown](https://github.com/mapbox/stylelint-processor-markdown): Lint within Markdown's [fenced code blocks](https://help.github.com/articles/creating-and-highlighting-code-blocks/).

270
node_modules/stylelint/docs/user-guide/rules.md generated vendored Normal file
View File

@@ -0,0 +1,270 @@
# Rules
Rules determine what the linter looks for and complains about. All the rules are turned off by default and none have default values for their options. The rules follow a consistent naming convention and have been designed to work in conjunction with one another, you can read more about this in the ["About rules"](about-rules.md) section.
In addition to these rules there are [plugins](plugins.md), which are rules built by the community that support methodologies, toolsets, *non-standard* CSS features, or very specific use cases. Don't forget to look at the list of [plugins](plugins.md) for more ways to lint.
## List of rules
Here are all the rules within stylelint, grouped by the [*thing*](http://apps.workflower.fi/vocabs/css/en) they apply to.
### Color
- [`color-hex-case`](../../lib/rules/color-hex-case/README.md): Specify lowercase or uppercase for hex colors.
- [`color-hex-length`](../../lib/rules/color-hex-length/README.md): Specify short or long notation for hex colors.
- [`color-named`](../../lib/rules/color-named/README.md): Require (where possible) or disallow named colors.
- [`color-no-hex`](../../lib/rules/color-no-hex/README.md): Disallow hex colors.
- [`color-no-invalid-hex`](../../lib/rules/color-no-invalid-hex/README.md): Disallow invalid hex colors.
### Font family
- [`font-family-name-quotes`](../../lib/rules/font-family-name-quotes/README.md): Specify whether or not quotation marks should be used around font family names.
- [`font-family-no-duplicate-names`](../../lib/rules/font-family-no-duplicate-names/README.md): Disallow duplicate font family names.
### Font weight
- [`font-weight-notation`](../../lib/rules/font-weight-notation/README.md): Require numeric or named (where possible) `font-weight` values.
### Function
- [`function-blacklist`](../../lib/rules/function-blacklist/README.md): Specify a blacklist of disallowed functions.
- [`function-calc-no-unspaced-operator`](../../lib/rules/function-calc-no-unspaced-operator/README.md): Disallow an unspaced operator within `calc` functions.
- [`function-comma-newline-after`](../../lib/rules/function-comma-newline-after/README.md): Require a newline or disallow whitespace after the commas of functions.
- [`function-comma-newline-before`](../../lib/rules/function-comma-newline-before/README.md): Require a newline or disallow whitespace before the commas of functions.
- [`function-comma-space-after`](../../lib/rules/function-comma-space-after/README.md): Require a single space or disallow whitespace after the commas of functions.
- [`function-comma-space-before`](../../lib/rules/function-comma-space-before/README.md): Require a single space or disallow whitespace before the commas of functions.
- [`function-linear-gradient-no-nonstandard-direction`](../../lib/rules/function-linear-gradient-no-nonstandard-direction/README.md): Disallow direction values in `linear-gradient()` calls that are not valid according to the [standard syntax](https://developer.mozilla.org/en-US/docs/Web/CSS/linear-gradient#Syntax).
- [`function-max-empty-lines`](../../lib/rules/function-max-empty-lines/README.md): Limit the number of adjacent empty lines within functions.
- [`function-name-case`](../../lib/rules/function-name-case/README.md): Specify lowercase or uppercase for function names.
- [`function-parentheses-newline-inside`](../../lib/rules/function-parentheses-newline-inside/README.md): Require a newline or disallow whitespace on the inside of the parentheses of functions.
- [`function-parentheses-space-inside`](../../lib/rules/function-parentheses-space-inside/README.md): Require a single space or disallow whitespace on the inside of the parentheses of functions.
- [`function-url-data-uris`](../../lib/rules/function-url-data-uris/README.md): Require or disallow data URIs for urls.
- [`function-url-no-scheme-relative`](../../lib/rules/function-url-no-scheme-relative/README.md): Disallow scheme-relative urls.
- [`function-url-quotes`](../../lib/rules/function-url-quotes/README.md): Require or disallow quotes for urls.
- [`function-url-scheme-whitelist`](../../lib/rules/function-url-scheme-whitelist/README.md): Specify a whitelist of allowed url schemes.
- [`function-whitelist`](../../lib/rules/function-whitelist/README.md): Specify a whitelist of allowed functions.
- [`function-whitespace-after`](../../lib/rules/function-whitespace-after/README.md): Require or disallow whitespace after functions.
### Number
- [`number-leading-zero`](../../lib/rules/number-leading-zero/README.md): Require or disallow a leading zero for fractional numbers less than 1.
- [`number-max-precision`](../../lib/rules/number-max-precision/README.md): Limit the number of decimal places allowed in numbers.
- [`number-no-trailing-zeros`](../../lib/rules/number-no-trailing-zeros/README.md): Disallow trailing zeros in numbers.
### String
- [`string-no-newline`](../../lib/rules/string-no-newline/README.md): Disallow (unescaped) newlines in strings.
- [`string-quotes`](../../lib/rules/string-quotes/README.md): Specify single or double quotes around strings.
### Length
- [`length-zero-no-unit`](../../lib/rules/length-zero-no-unit/README.md): Disallow units for zero lengths.
### Time
- [`time-min-milliseconds`](../../lib/rules/time-min-milliseconds/README.md): Specify the minimum number of milliseconds for time values.
- [`time-no-imperceptible`](../../lib/rules/time-no-imperceptible/README.md): Disallow `animation` and `transition` less than or equal to 100ms (deprecated).
### Unit
- [`unit-blacklist`](../../lib/rules/unit-blacklist/README.md): Specify a blacklist of disallowed units.
- [`unit-case`](../../lib/rules/unit-case/README.md): Specify lowercase or uppercase for units.
- [`unit-no-unknown`](../../lib/rules/unit-no-unknown/README.md): Disallow unknown units.
- [`unit-whitelist`](../../lib/rules/unit-whitelist/README.md): Specify a whitelist of allowed units.
### Value
- [`value-keyword-case`](../../lib/rules/value-keyword-case/README.md): Specify lowercase or uppercase for keywords values.
- [`value-no-vendor-prefix`](../../lib/rules/value-no-vendor-prefix/README.md): Disallow vendor prefixes for values.
### Value list
- [`value-list-comma-newline-after`](../../lib/rules/value-list-comma-newline-after/README.md): Require a newline or disallow whitespace after the commas of value lists.
- [`value-list-comma-newline-before`](../../lib/rules/value-list-comma-newline-before/README.md): Require a newline or disallow whitespace before the commas of value lists.
- [`value-list-comma-space-after`](../../lib/rules/value-list-comma-space-after/README.md): Require a single space or disallow whitespace after the commas of value lists.
- [`value-list-comma-space-before`](../../lib/rules/value-list-comma-space-before/README.md): Require a single space or disallow whitespace before the commas of value lists.
- [`value-list-max-empty-lines`](../../lib/rules/value-list-max-empty-lines/README.md): Limit the number of adjacent empty lines within value lists.
### Custom property
- [`custom-property-empty-line-before`](../../lib/rules/custom-property-empty-line-before/README.md): Require or disallow an empty line before custom properties.
- [`custom-property-no-outside-root`](../../lib/rules/custom-property-no-outside-root/README.md): Disallow custom properties outside of `:root` rules (deprecated).
- [`custom-property-pattern`](../../lib/rules/custom-property-pattern/README.md): Specify a pattern for custom properties.
### Shorthand property
- [`shorthand-property-no-redundant-values`](../../lib/rules/shorthand-property-no-redundant-values/README.md): Disallow redundant values in shorthand properties.
### Property
- [`property-blacklist`](../../lib/rules/property-blacklist/README.md): Specify a blacklist of disallowed properties.
- [`property-case`](../../lib/rules/property-case/README.md): Specify lowercase or uppercase for properties.
- [`property-no-unknown`](../../lib/rules/property-no-unknown/README.md): Disallow unknown properties.
- [`property-no-vendor-prefix`](../../lib/rules/property-no-vendor-prefix/README.md): Disallow vendor prefixes for properties.
- [`property-whitelist`](../../lib/rules/property-whitelist/README.md): Specify a whitelist of allowed properties.
### Keyframe declaration
- [`keyframe-declaration-no-important`](../../lib/rules/keyframe-declaration-no-important/README.md): Disallow `!important` within keyframe declarations.
### Declaration
- [`declaration-bang-space-after`](../../lib/rules/declaration-bang-space-after/README.md): Require a single space or disallow whitespace after the bang of declarations.
- [`declaration-bang-space-before`](../../lib/rules/declaration-bang-space-before/README.md): Require a single space or disallow whitespace before the bang of declarations.
- [`declaration-colon-newline-after`](../../lib/rules/declaration-colon-newline-after/README.md): Require a newline or disallow whitespace after the colon of declarations.
- [`declaration-colon-space-after`](../../lib/rules/declaration-colon-space-after/README.md): Require a single space or disallow whitespace after the colon of declarations.
- [`declaration-colon-space-before`](../../lib/rules/declaration-colon-space-before/README.md): Require a single space or disallow whitespace before the colon of declarations.
- [`declaration-empty-line-before`](../../lib/rules/declaration-empty-line-before/README.md): Require or disallow an empty line before declarations.
- [`declaration-no-important`](../../lib/rules/declaration-no-important/README.md): Disallow `!important` within declarations.
- [`declaration-property-unit-blacklist`](../../lib/rules/declaration-property-unit-blacklist/README.md): Specify a blacklist of disallowed property and unit pairs within declarations.
- [`declaration-property-unit-whitelist`](../../lib/rules/declaration-property-unit-whitelist/README.md): Specify a whitelist of allowed property and unit pairs within declarations.
- [`declaration-property-value-blacklist`](../../lib/rules/declaration-property-value-blacklist/README.md): Specify a blacklist of disallowed property and value pairs within declarations.
- [`declaration-property-value-whitelist`](../../lib/rules/declaration-property-value-whitelist/README.md): Specify a whitelist of allowed property and value pairs within declarations.
### Declaration block
- [`declaration-block-no-duplicate-properties`](../../lib/rules/declaration-block-no-duplicate-properties/README.md): Disallow duplicate properties within declaration blocks.
- [`declaration-block-no-ignored-properties`](../../lib/rules/declaration-block-no-ignored-properties/README.md): Disallow property values that are ignored due to another property value in the same rule (deprecated).
- [`declaration-block-no-redundant-longhand-properties`](../../lib/rules/declaration-block-no-redundant-longhand-properties/README.md): Disallow longhand properties that can be combined into one shorthand property.
- [`declaration-block-no-shorthand-property-overrides`](../../lib/rules/declaration-block-no-shorthand-property-overrides/README.md): Disallow shorthand properties that override related longhand properties within declaration blocks.
- [`declaration-block-properties-order`](../../lib/rules/declaration-block-properties-order/README.md): Specify the order of properties within declaration blocks (deprecated).
- [`declaration-block-semicolon-newline-after`](../../lib/rules/declaration-block-semicolon-newline-after/README.md): Require a newline or disallow whitespace after the semicolons of declaration blocks.
- [`declaration-block-semicolon-newline-before`](../../lib/rules/declaration-block-semicolon-newline-before/README.md): Require a newline or disallow whitespace before the semicolons of declaration blocks.
- [`declaration-block-semicolon-space-after`](../../lib/rules/declaration-block-semicolon-space-after/README.md): Require a single space or disallow whitespace after the semicolons of declaration blocks.
- [`declaration-block-semicolon-space-before`](../../lib/rules/declaration-block-semicolon-space-before/README.md): Require a single space or disallow whitespace before the semicolons of declaration blocks.
- [`declaration-block-single-line-max-declarations`](../../lib/rules/declaration-block-single-line-max-declarations/README.md): Limit the number of declaration within single line declaration blocks.
- [`declaration-block-trailing-semicolon`](../../lib/rules/declaration-block-trailing-semicolon/README.md): Require or disallow a trailing semicolon within declaration blocks.
### Block
- [`block-closing-brace-empty-line-before`](../../lib/rules/block-closing-brace-empty-line-before/README.md): Require or disallow an empty line before the closing brace of blocks.
- [`block-closing-brace-newline-after`](../../lib/rules/block-closing-brace-newline-after/README.md): Require a newline or disallow whitespace after the closing brace of blocks.
- [`block-closing-brace-newline-before`](../../lib/rules/block-closing-brace-newline-before/README.md): Require a newline or disallow whitespace before the closing brace of blocks.
- [`block-closing-brace-space-after`](../../lib/rules/block-closing-brace-space-after/README.md): Require a single space or disallow whitespace after the closing brace of blocks.
- [`block-closing-brace-space-before`](../../lib/rules/block-closing-brace-space-before/README.md): Require a single space or disallow whitespace before the closing brace of blocks.
- [`block-no-empty`](../../lib/rules/block-no-empty/README.md): Disallow empty blocks.
- [`block-no-single-line`](../../lib/rules/block-no-single-line/README.md): Disallow single-line blocks (deprecated).
- [`block-opening-brace-newline-after`](../../lib/rules/block-opening-brace-newline-after/README.md): Require a newline after the opening brace of blocks.
- [`block-opening-brace-newline-before`](../../lib/rules/block-opening-brace-newline-before/README.md): Require a newline or disallow whitespace before the opening brace of blocks.
- [`block-opening-brace-space-after`](../../lib/rules/block-opening-brace-space-after/README.md): Require a single space or disallow whitespace after the opening brace of blocks.
- [`block-opening-brace-space-before`](../../lib/rules/block-opening-brace-space-before/README.md): Require a single space or disallow whitespace before the opening brace of blocks.
### Selector
- [`selector-attribute-brackets-space-inside`](../../lib/rules/selector-attribute-brackets-space-inside/README.md): Require a single space or disallow whitespace on the inside of the brackets within attribute selectors.
- [`selector-attribute-operator-blacklist`](../../lib/rules/selector-attribute-operator-blacklist/README.md): Specify a blacklist of disallowed attribute operators.
- [`selector-attribute-operator-space-after`](../../lib/rules/selector-attribute-operator-space-after/README.md): Require a single space or disallow whitespace after operators within attribute selectors.
- [`selector-attribute-operator-space-before`](../../lib/rules/selector-attribute-operator-space-before/README.md): Require a single space or disallow whitespace before operators within attribute selectors.
- [`selector-attribute-operator-whitelist`](../../lib/rules/selector-attribute-operator-whitelist/README.md): Specify a whitelist of allowed attribute operators.
- [`selector-attribute-quotes`](../../lib/rules/selector-attribute-quotes/README.md): Require or disallow quotes for attribute values.
- [`selector-class-pattern`](../../lib/rules/selector-class-pattern/README.md): Specify a pattern for class selectors.
- [`selector-combinator-space-after`](../../lib/rules/selector-combinator-space-after/README.md): Require a single space or disallow whitespace after the combinators of selectors.
- [`selector-combinator-space-before`](../../lib/rules/selector-combinator-space-before/README.md): Require a single space or disallow whitespace before the combinators of selectors.
- [`selector-descendant-combinator-no-non-space`](../../lib/rules/selector-descendant-combinator-no-non-space/README.md): Disallow non-space characters for descendant combinators of selectors.
- [`selector-id-pattern`](../../lib/rules/selector-id-pattern/README.md): Specify a pattern for id selectors.
- [`selector-max-compound-selectors`](../../lib/rules/selector-max-compound-selectors/README.md): Limit the number of compound selectors in a selector.
- [`selector-max-specificity`](../../lib/rules/selector-max-specificity/README.md): Limit the specificity of selectors.
- [`selector-nested-pattern`](../../lib/rules/selector-nested-pattern/README.md): Specify a pattern for the selectors of rules nested within rules.
- [`selector-no-attribute`](../../lib/rules/selector-no-attribute/README.md): Disallow attribute selectors.
- [`selector-no-combinator`](../../lib/rules/selector-no-combinator/README.md): Disallow combinators in selectors.
- [`selector-no-empty`](../../lib/rules/selector-no-empty/README.md): Disallow empty selectors (deprecated).
- [`selector-no-id`](../../lib/rules/selector-no-id/README.md): Disallow id selectors.
- [`selector-no-qualifying-type`](../../lib/rules/selector-no-qualifying-type/README.md): Disallow qualifying a selector by type.
- [`selector-no-type`](../../lib/rules/selector-no-type/README.md): Disallow type selectors.
- [`selector-no-universal`](../../lib/rules/selector-no-universal/README.md): Disallow the universal selector.
- [`selector-no-vendor-prefix`](../../lib/rules/selector-no-vendor-prefix/README.md): Disallow vendor prefixes for selectors.
- [`selector-pseudo-class-blacklist`](../../lib/rules/selector-pseudo-class-blacklist/README.md): Specify a blacklist of disallowed pseudo-class selectors.
- [`selector-pseudo-class-case`](../../lib/rules/selector-pseudo-class-case/README.md): Specify lowercase or uppercase for pseudo-class selectors.
- [`selector-pseudo-class-no-unknown`](../../lib/rules/selector-pseudo-class-no-unknown/README.md): Disallow unknown pseudo-class selectors.
- [`selector-pseudo-class-parentheses-space-inside`](../../lib/rules/selector-pseudo-class-parentheses-space-inside/README.md): Require a single space or disallow whitespace on the inside of the parentheses within pseudo-class selectors.
- [`selector-pseudo-class-whitelist`](../../lib/rules/selector-pseudo-class-whitelist/README.md): Specify a whitelist of allowed pseudo-class selectors.
- [`selector-pseudo-element-case`](../../lib/rules/selector-pseudo-element-case/README.md): Specify lowercase or uppercase for pseudo-element selectors.
- [`selector-pseudo-element-colon-notation`](../../lib/rules/selector-pseudo-element-colon-notation/README.md): Specify single or double colon notation for applicable pseudo-elements.
- [`selector-pseudo-element-no-unknown`](../../lib/rules/selector-pseudo-element-no-unknown/README.md): Disallow unknown pseudo-element selectors.
- [`selector-root-no-composition`](../../lib/rules/selector-root-no-composition/README.md): Disallow the composition of `:root` in selectors (deprecated).
- [`selector-type-case`](../../lib/rules/selector-type-case/README.md): Specify lowercase or uppercase for type selector.
- [`selector-type-no-unknown`](../../lib/rules/selector-type-no-unknown/README.md): Disallow unknown type selectors.
- [`selector-max-empty-lines`](../../lib/rules/selector-max-empty-lines/README.md): Limit the number of adjacent empty lines within selectors.
### Selector list
- [`selector-list-comma-newline-after`](../../lib/rules/selector-list-comma-newline-after/README.md): Require a newline or disallow whitespace after the commas of selector lists.
- [`selector-list-comma-newline-before`](../../lib/rules/selector-list-comma-newline-before/README.md): Require a newline or disallow whitespace before the commas of selector lists.
- [`selector-list-comma-space-after`](../../lib/rules/selector-list-comma-space-after/README.md): Require a single space or disallow whitespace after the commas of selector lists.
- [`selector-list-comma-space-before`](../../lib/rules/selector-list-comma-space-before/README.md): Require a single space or disallow whitespace before the commas of selector lists.
### Root rule
- [`root-no-standard-properties`](../../lib/rules/root-no-standard-properties/README.md): Disallow standard properties inside `:root` rules (deprecated).
### Rule
- [`rule-empty-line-before`](../../lib/rules/rule-empty-line-before/README.md): Require or disallow an empty line before rules.
- [`rule-nested-empty-line-before`](../../lib/rules/rule-nested-empty-line-before/README.md): Require or disallow an empty line before nested rules (deprecated).
- [`rule-non-nested-empty-line-before`](../../lib/rules/rule-non-nested-empty-line-before/README.md): Require or disallow an empty line before non-nested rules (deprecated).
### Media feature
- [`media-feature-colon-space-after`](../../lib/rules/media-feature-colon-space-after/README.md): Require a single space or disallow whitespace after the colon in media features.
- [`media-feature-colon-space-before`](../../lib/rules/media-feature-colon-space-before/README.md): Require a single space or disallow whitespace before the colon in media features.
- [`media-feature-name-blacklist`](../../lib/rules/media-feature-name-blacklist/README.md): Specify a blacklist of disallowed media feature names.
- [`media-feature-name-case`](../../lib/rules/media-feature-name-case/README.md): Specify lowercase or uppercase for media feature names.
- [`media-feature-name-no-unknown`](../../lib/rules/media-feature-name-no-unknown/README.md): Disallow unknown media feature names.
- [`media-feature-name-no-vendor-prefix`](../../lib/rules/media-feature-name-no-vendor-prefix/README.md): Disallow vendor prefixes for media feature names.
- [`media-feature-name-whitelist`](../../lib/rules/media-feature-name-whitelist/README.md): Specify a whitelist of allowed media feature names.
- [`media-feature-no-missing-punctuation`](../../lib/rules/media-feature-no-missing-punctuation/README.md): Disallow missing punctuation for non-boolean media features (deprecated).
- [`media-feature-parentheses-space-inside`](../../lib/rules/media-feature-parentheses-space-inside/README.md): Require a single space or disallow whitespace on the inside of the parentheses within media features.
- [`media-feature-range-operator-space-after`](../../lib/rules/media-feature-range-operator-space-after/README.md): Require a single space or disallow whitespace after the range operator in media features.
- [`media-feature-range-operator-space-before`](../../lib/rules/media-feature-range-operator-space-before/README.md): Require a single space or disallow whitespace before the range operator in media features.
### Custom media
- [`custom-media-pattern`](../../lib/rules/custom-media-pattern/README.md): Specify a pattern for custom media query names.
### Media query list
- [`media-query-list-comma-newline-after`](../../lib/rules/media-query-list-comma-newline-after/README.md): Require a newline or disallow whitespace after the commas of media query lists.
- [`media-query-list-comma-newline-before`](../../lib/rules/media-query-list-comma-newline-before/README.md): Require a newline or disallow whitespace before the commas of media query lists.
- [`media-query-list-comma-space-after`](../../lib/rules/media-query-list-comma-space-after/README.md): Require a single space or disallow whitespace after the commas of media query lists.
- [`media-query-list-comma-space-before`](../../lib/rules/media-query-list-comma-space-before/README.md): Require a single space or disallow whitespace before the commas of media query lists.
### At-rule
- [`at-rule-blacklist`](../../lib/rules/at-rule-blacklist/README.md): Specify a blacklist of disallowed at-rules.
- [`at-rule-empty-line-before`](../../lib/rules/at-rule-empty-line-before/README.md): Require or disallow an empty line before at-rules.
- [`at-rule-name-case`](../../lib/rules/at-rule-name-case/README.md): Specify lowercase or uppercase for at-rules names.
- [`at-rule-name-newline-after`](../../lib/rules/at-rule-name-newline-after/README.md): Require a newline after at-rule names.
- [`at-rule-name-space-after`](../../lib/rules/at-rule-name-space-after/README.md): Require a single space after at-rule names.
- [`at-rule-no-unknown`](../../lib/rules/at-rule-no-unknown/README.md): Disallow unknown at-rules.
- [`at-rule-no-vendor-prefix`](../../lib/rules/at-rule-no-vendor-prefix/README.md): Disallow vendor prefixes for at-rules.
- [`at-rule-semicolon-newline-after`](../../lib/rules/at-rule-semicolon-newline-after/README.md): Require a newline after the semicolon of at-rules.
- [`at-rule-whitelist`](../../lib/rules/at-rule-whitelist/README.md): Specify a whitelist of allowed at-rules.
### `stylelint-disable` comment
- [`stylelint-disable-reason`](../../lib/rules/stylelint-disable-reason/README.md): Require a reason comment before or after `stylelint-disable` comments (deprecated).
### Comment
- [`comment-empty-line-before`](../../lib/rules/comment-empty-line-before/README.md): Require or disallow an empty line before comments.
- [`comment-no-empty`](../../lib/rules/comment-no-empty/README.md): Disallow empty comments.
- [`comment-whitespace-inside`](../../lib/rules/comment-whitespace-inside/README.md): Require or disallow whitespace on the inside of comment markers.
- [`comment-word-blacklist`](../../lib/rules/comment-word-blacklist/README.md): Specify a blacklist of disallowed words within comments.
### General / Sheet
- [`indentation`](../../lib/rules/indentation/README.md): Specify indentation.
- [`max-empty-lines`](../../lib/rules/max-empty-lines/README.md): Limit the number of adjacent empty lines.
- [`max-line-length`](../../lib/rules/max-line-length/README.md): Limit the length of a line.
- [`max-nesting-depth`](../../lib/rules/max-nesting-depth/README.md): Limit the depth of nesting.
- [`no-browser-hacks`](../../lib/rules/no-browser-hacks/README.md): Disallow browser hacks that are irrelevant to the browsers you are targeting (deprecated).
- [`no-descending-specificity`](../../lib/rules/no-descending-specificity/README.md): Disallow selectors of lower specificity from coming after overriding selectors of higher specificity.
- [`no-duplicate-selectors`](../../lib/rules/no-duplicate-selectors/README.md): Disallow duplicate selectors.
- [`no-empty-source`](../../lib/rules/no-empty-source/README.md): Disallow empty sources.
- [`no-eol-whitespace`](../../lib/rules/no-eol-whitespace/README.md): Disallow end-of-line whitespace.
- [`no-extra-semicolons`](../../lib/rules/no-extra-semicolons/README.md): Disallow extra semicolons.
- [`no-indistinguishable-colors`](../../lib/rules/no-indistinguishable-colors/README.md): Disallow colors that are suspiciously close to being identical (deprecated).
- [`no-invalid-double-slash-comments`](../../lib/rules/no-invalid-double-slash-comments/README.md): Disallow double-slash comments (`//...`) which are not supported by CSS.
- [`no-missing-end-of-source-newline`](../../lib/rules/no-missing-end-of-source-newline/README.md): Disallow missing end-of-source newlines.
- [`no-unknown-animations`](../../lib/rules/no-unknown-animations/README.md): Disallow unknown animations.
- [`no-unsupported-browser-features`](../../lib/rules/no-unsupported-browser-features/README.md): Disallow features that are unsupported by the browsers that you are targeting (deprecated).