added all files to project

node_modules/stylelint/docs/about/linting.md

@@ -0,0 +1,34 @@
+# Linting
+
+A linter is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs.
+
+You can use a linter with a pretty printer and a validator. There are, however, usually overlaps between these three types of tools.
+
+## Pretty printers
+
+There are two approaches to enforcing stylistic conventions:
+
+- a machine algorithmically pretty prints the code (usually based on a maximum line length)
+- a human initially formats the code, and a machine fixes-up/warns-about any mistakes
+
+The former is handled by pretty printers, like [prettier](https://github.com/prettier/prettier), whereas the latter is catered for by the built-in [stylistic rules](../user-guide/rules/list.md#stylistic-issues). If you use a pretty printer, you'll want to use [`stylelint-config-recommended`](https://github.com/stylelint/stylelint-config-recommended), which only turns on [possible error](../user-guide/rules/list.md#possible-errors) rules.
+
+Additionally, the built-in stylistic rules and plugins are configurable to support a diverse range of stylistic conventions. For example, ordering properties within declaration blocks is a divisive topic, where there isn't a dominant convention. The [`stylelint-order`](https://www.npmjs.com/package/stylelint-order) plugin can be configured to lint and fix a diverse range of ordering conventions.
+
+Another example is the use of single-line rules for sets of _related_ rules, e.g.
+
+<!-- prettier-ignore -->
+```css
+/* Single-line related classes */
+.class-1 { top: 0; bottom: 0; }
+.class-2 { top: 5px; right: 0; }
+.class-3 { top: 8px; left: 0; }
+```
+
+You can configure the built-in stylistic rules to allow both multi-line and single-line rules. The choice of when to use each belongs to the user.
+
+## Validators
+
+Validators like [csstree](https://github.com/csstree/csstree) identify invalid code such as misformed hex colors and unknown language features.
+
+However, as a stop-gap, while these tools mature stylelint provides rules for the simplest of cases.

node_modules/stylelint/docs/about/semantic-versioning.md

@@ -0,0 +1,37 @@
+# Semantic versioning
+
+Due to the nature of stylelint as a code quality tool, we follow a specific flavor of [semantic versioning](http://semver.org).
+
+Any minor update may report more errors than the previous release. As such, we recommend using the tilde (`~`) in `package.json` e.g. `"stylelint": "~7.2.0"` to guarantee the results of your builds.
+
+## Patch release
+
+Intended not to break your lint build:
+
+- a bug fix in a rule that results in stylelint reporting fewer errors
+- a bug fix to the CLI or core (including formatters)
+- improvements to documentation
+- non-user-facing changes such as refactoring code or modifying tests
+- re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone)
+
+## Minor release
+
+Might break your lint build:
+
+- a bug fix in a rule that results in stylelint reporting more errors
+- a new rule is created
+- a new option to an existing rule that does not result in stylelint reporting more errors by default
+- an existing rule is deprecated
+- a new CLI capability is created
+- a new public API capability is created
+- a new formatter is created
+
+## Major release
+
+Likely to break your lint build:
+
+- a change in the documented behavior of an existing rule results in stylelint reporting more errors by default
+- an existing rule is removed
+- an existing formatter is removed
+- part of the CLI is removed or changed in an incompatible way
+- part of the public API is removed or changed in an incompatible way

node_modules/stylelint/docs/about/syntaxes.md

@@ -0,0 +1,18 @@
+# Syntaxes
+
+There are many styling languages, ranging from CSS language extensions like SCSS to entirely different notations, e.g. CSS-in-JS objects.
+
+These styling languages can be embedded within other languages too. For example:
+
+- HTML `<style>` tags
+- markdown fences
+- JavaScript template literals
+
+We aim to support all these use cases in stylelint, but it's a complicated endeavor.
+
+We lean on [PostCSS syntaxes](https://github.com/postcss/postcss#syntaxes) to help us with this task. We use them to transform these languages into something that resembles CSS, which is the language that:
+
+- underpins all the other styling languages
+- is best understood by rules built into stylelint
+
+If you write your styles in anything other than CSS, please consider [contributing to these syntaxes](../developer-guide/syntaxes.md) so that they can remain compatible with stylelint.

node_modules/stylelint/docs/about/vision.md

@@ -0,0 +1,63 @@
+# Vision
+
+A linter for CSS and CSS-like languages that is:
+
+- complete - coverage of all standard CSS syntax
+- extensible - multiple points of extension
+- configurable - no defaults and options to tailor the linter
+- robust - comprehensive test coverage and a wide range of fixtures
+- consistent - conventions for behavior, naming and documentation
+- performant - tools to test and improve performance
+
+## Complete
+
+Provide built-in rules for standard CSS syntax that:
+
+- [detect possible errors](../user-guide/rules/list.md#possible-errors)
+- [limit language features](../user-guide/rules/list.md#limit-language-features)
+- [enforce stylistic conventions](../user-guide/rules/list.md#stylistic-issues)
+
+### Possible errors
+
+Provide rules to catch code that is valid but likely has unintended consequences, e.g. duplicates and overrides.
+
+### Limit language features
+
+Provide rules to limit what language features can be used to enforce:
+
+- a maximum specificity by limiting the overall specificity or the occurrence of different selector types, e.g. class, ID and attribute
+- best practice _at the configuration level_, e.g. disallowing the `all` keyword for transitions
+- the use of a subset of features to improve consistency across a codebase, e.g. limiting what units are allowed
+- specific patterns for selectors and names, e.g. those of custom properties
+
+### Stylistic issues
+
+Provide rules to enforce a diverse range of stylistic conventions, including:
+
+- whitespace
+- case
+- quotes
+
+## Extensible
+
+Provide multiple points of extensions, including:
+
+- [plugins](../developer-guide/plugins.md) - build community rules to support methodologies, toolsets, non-standard CSS features, or very specific use cases
+- [extendable configs](../user-guide/configure.md#extends) - extend and share configurations
+- [formatters](../developer-guide/formatters.md) - format stylelint result objects
+- [custom syntax](syntaxes.md) - use any PostCSS-compatible syntax module
+
+## Robust
+
+Provide a robust tool with a [comprehensive test suite](../developer-guide/rules.md#write-tests), including:
+
+- high coverage, currently over 95%
+- a wide range of fixtures for rules
+
+## Consistent
+
+Provide consistency throughout, including consistent [rules](../user-guide/rules/about.md).
+
+## Performant
+
+Provide a fast tool and the means to test and improve performance, including [benchmarking](../developer-guide/rules.md#improve-the-performance-of-a-rule) of an individual rule's performance.

node_modules/stylelint/docs/developer-guide/formatters.md

@@ -0,0 +1,77 @@
+# Writing formatters
+
+A formatter is a function with the following signature:
+
+```js
+/**
+ * @type {import('stylelint').Formatter}
+ */
+function formatter(results, returnValue) {
+  return "a string of formatted results";
+}
+```
+
+Where the first argument (`results`) is an array of stylelint result objects (type `Array<StylelintResult>`) in the form:
+
+```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
+}
+```
+
+And the second argument (`returnValue`) is an object (type `StylelintStandaloneReturnValue`) with one or more of the following keys:
+
+```js
+{
+  "errored": false, // `true` if there were any warnings with "error" severity
+  "maxWarningsExceeded": {
+    // Present if stylelint was configured with a `maxWarnings` count
+    "maxWarnings": 10,
+    "foundWarnings": 15
+  }
+}
+```
+
+## Passing arguments
+
+You can use environmental variables in your formatter. For example, pass `SKIP_WARNINGS`:
+
+```console
+SKIP_WARNINGS=true stylelint "*.css" --custom-formatter ./my-formatter.js
+```
+
+Alternatively, you can create a separate formatting program and pipe the output from the built-in JSON formatter into it:
+
+```console
+stylelint -f json "*.css" | my-program-that-reads-JSON --option
+```
+
+## `stylelint.formatters`
+
+stylelint's internal formatters are exposed publicly in `stylelint.formatters`.

node_modules/stylelint/docs/developer-guide/plugins.md

@@ -0,0 +1,324 @@
+# Writing plugins
+
+Plugins are rules and sets of rules built by the community.
+
+We recommend your plugin adheres to [stylelint's conventions](rules.md) for:
+
+- names
+- options
+- messages
+- tests
+- docs
+
+## The anatomy of a plugin
+
+```js
+// Abbreviated example
+const stylelint = require("stylelint");
+
+const ruleName = "plugin/foo-bar";
+const messages = stylelint.utils.ruleMessages(ruleName, {
+  expected: "Expected ..."
+});
+
+module.exports = stylelint.createPlugin(
+  ruleName,
+  function (primaryOption, secondaryOptionObject) {
+    return function (postcssRoot, postcssResult) {
+      const 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`, to ensure it never clashes with the built-in rules. If your plugin provides only a single rule or you can't think of a good namespace, you can use `plugin/my-rule`. _You should document your plugin's rule name (and namespace) because users need to use them in their config._
+
+Use `stylelint.createPlugin(ruleName, ruleFunction)` to ensure that your plugin is set up properly alongside other rules.
+
+For your plugin rule to work with the [standard configuration format](../user-guide/configure.md#rules), `ruleFunction` should accept 2 arguments:
+
+- the primary option
+- optionally, a secondary options object
+
+If your plugin rule supports [autofixing](rules.md#add-autofix), then `ruleFunction` should also accept a third argument: `context`. You should try to support the `disableFix` option in your secondary options object. Within the rule, don't perform autofixing if the user has passed a `disableFix` option for your rule.
+
+`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)
+- the PostCSS LazyResult
+
+You'll have to [learn about the PostCSS API](https://api.postcss.org/).
+
+### Asynchronous rules
+
+You can return a `Promise` instance from your plugin function to create an asynchronous rule.
+
+```js
+// Abbreviated asynchronous example
+const stylelint = require("stylelint");
+
+const ruleName = "plugin/foo-bar-async";
+const messages = stylelint.utils.ruleMessages(ruleName, {
+  expected: "Expected ..."
+});
+
+module.exports = stylelint.createPlugin(
+  ruleName,
+  function (primaryOption, secondaryOptionObject) {
+    return function (postcssRoot, postcssResult) {
+      const validOptions = stylelint.utils.validateOptions(
+        postcssResult,
+        ruleName,
+        {
+          /* .. */
+        }
+      );
+
+      if (!validOptions) {
+        return;
+      }
+
+      return new Promise(function (resolve) {
+        // some async operation
+        setTimeout(function () {
+          // ... some logic ...
+          stylelint.utils.report({
+            /* .. */
+          });
+          resolve();
+        }, 1);
+      });
+    };
+  }
+);
+
+module.exports.ruleName = ruleName;
+module.exports.messages = messages;
+```
+
+## Testing
+
+You should use [`jest-preset-stylelint`](https://github.com/stylelint/jest-preset-stylelint) to test your plugin. The preset exposes a global `testRule` function that you can use to efficiently test your plugin using a schema.
+
+For example:
+
+```js
+// index.test.js
+const { messages, ruleName } = require(".");
+
+testRule({
+  plugins: ["./index.js"],
+  ruleName,
+  config: true,
+  fix: true,
+
+  accept: [
+    {
+      code: ".class {}"
+    },
+    {
+      code: ".my-class {}"
+    }
+  ],
+
+  reject: [
+    {
+      code: ".myClass {}",
+      fixed: ".my-class {}",
+      message: messages.expected(),
+      line: 1,
+      column: 1
+    }
+  ]
+});
+```
+
+However, if your plugin involves more than just checking syntax you can use stylelint directly.
+
+For example:
+
+```js
+// index.test.js
+const { lint } = require("stylelint");
+
+const config = {
+  plugins: ["./index.js"],
+  rules: {
+    "plugin/at-import-no-unresolveable": [true]
+  }
+};
+
+it("warns for unresolveable import", async () => {
+  const {
+    results: [{ warnings, parseErrors }]
+  } = await lint({
+    files: "fixtures/contains-unresolveable-import.css",
+    config
+  });
+
+  expect(parseErrors).toHaveLength(0);
+  expect(warnings).toHaveLength(1);
+
+  const [{ line, column, text }] = warnings;
+
+  expect(text).toBe(
+    "Unexpected unresolveable import (plugin/at-import-no-unresolveable)"
+  );
+  expect(line).toBe(1);
+  expect(column).toBe(1);
+});
+
+it("doesn't warn for fileless sources", async () => {
+  const {
+    results: [{ warnings, parseErrors }]
+  } = await lint({
+    code: "@import url(unknown.css)",
+    config
+  });
+  expect(parseErrors).toHaveLength(0);
+  expect(warnings).toHaveLength(0);
+});
+```
+
+Alternatively, if you don't want to use Jest you'll find more tools in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#tools).
+
+## `stylelint.utils`
+
+stylelint exposes some useful utilities.
+
+### `stylelint.utils.report`
+
+Adds violations from your plugin to the list of violations that stylelint will report to the user.
+
+Use `stylelint.utils.report` to ensure your plugin respects disabled ranges and other possible future features of stylelint. _Do not use PostCSS's `node.warn()` method directly._
+
+### `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.
+
+It 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
+- `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, secondaryOptionObject) {
+  return function (postcssRoot, postcssResult) {
+    const defaultedOptions = Object.assign({}, secondaryOptionObject, {
+      ignoreAtRules: allowableAtRules.concat(options.ignoreAtRules || [])
+    });
+
+    stylelint.utils.checkAgainstRule(
+      {
+        ruleName: "at-rule-no-unknown",
+        ruleSettings: [primaryOption, defaultedOptions],
+        root: postcssRoot
+      },
+      (warning) => {
+        stylelint.utils.report({
+          message: myMessage,
+          ruleName: myRuleName,
+          result: postcssResult,
+          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 an 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
+module.exports = 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) 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.
+
+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 an external module.
+
+## Peer dependencies
+
+You should express, within the `peerDependencies` key (and **not** within the `dependencies` key) of your plugin's `package.json`, what version(s) of stylelint your plugin can be used with. This is to ensure that different versions of stylelint are not unexpectedly installed.
+
+For example, to express that your plugin can be used with stylelint versions 7 and 8:
+
+```json
+{
+  "peerDependencies": {
+    "stylelint": "^7.0.0 || ^8.0.0"
+  }
+}
+```
+
+## Plugin packs
+
+To make a single module provide multiple rules, 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`.

node_modules/stylelint/docs/developer-guide/processors.md

@@ -0,0 +1,28 @@
+# 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.
+
+**Their use is discouraged in favor of [PostCSS syntaxes](../about/syntaxes.md).**
+
+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;
+    }
+  };
+};
+```
+
+_Processor options must be JSON-friendly_ because users will need to include them in `.stylelintrc` files.

node_modules/stylelint/docs/developer-guide/rules.md

@@ -0,0 +1,244 @@
+# Working on rules
+
+Please help us create, enhance, and debug our rules!
+
+## Add a rule
+
+You should:
+
+1. Get yourself ready to [contribute code](../../CONTRIBUTING.md#code-contributions).
+2. Familiarize yourself with the [conventions and patterns](../user-guide/rules/about.md) for rules.
+
+### Write the rule
+
+When writing the rule, you should:
+
+- make the rule strict by default
+- add secondary `ignore` options to make the rule more permissive
+- not include code specific to language extensions, e.g. SCSS
+
+You should make use of the:
+
+- PostCSS API
+- construct-specific parsers
+- utility functions
+
+#### PostCSS API
+
+Use the [PostCSS API](https://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.
+
+When using array methods on nodes, e.g. `find`, `some`, `filter` etc, you should explicitly check the `type` property of the node before attempting to access other properties. For example:
+
+```js
+const hasProperty = nodes.find(
+  ({ type, prop }) => type === "decl" && prop === propertyName
+);
+```
+
+Use `node.raws` instead of `node.raw()` when accessing raw strings from the [PostCSS AST](https://astexplorer.net/#/gist/ef718daf3e03f1d200b03dc5a550ec60/c8cbe9c6809a85894cebf3fb66de46215c377f1a).
+
+#### Construct-specific parsers
+
+Depending on the rule, we also recommend using:
+
+- [postcss-value-parser](https://github.com/TrySound/postcss-value-parser)
+- [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).
+
+#### Utility functions
+
+stylelint has [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!).
+
+Use the:
+
+- `validateOptions()` utility to warn users about invalid options
+- `isStandardSyntax*` utilities to ignore non-standard syntax
+
+### Add options
+
+Only add an option to a rule if it addresses a _requested_ use case to avoid polluting the tool with unused features.
+
+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;
+
+module.exports = 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 make an array the only possibility, instead of allowing for various data structures.
+
+### Add autofix
+
+Depending on the rule, it might be possible to automatically fix the rule's violations by mutating the PostCSS AST (Abstract Syntax Tree) using the [PostCSS API](http://api.postcss.org/).
+
+Add `context` variable to rule parameters:
+
+```js
+function rule(primary, secondary, context) {
+  return (root, result) => {
+    /* .. */
+  };
+}
+```
+
+`context` is an object which could have two properties:
+
+- `fix`(boolean): If `true`, your rule can apply autofixes.
+- `newline`(string): Line-ending used in current linted file.
+
+If `context.fix` is `true`, then change `root` using PostCSS API and return early before `report()` is called.
+
+```js
+if (context.fix) {
+  // Apply fixes using PostCSS API
+  return; // Return and don't report a problem
+}
+
+report(/* .. */);
+```
+
+### Write tests
+
+Each rule must have tests that cover all patterns that:
+
+- are considered violations
+- should _not_ be considered violations
+
+Write as many as you can stand to.
+
+You should:
+
+- test errors in multiple positions, not the same place every time
+- use realistic (if simple) CSS, and avoid the use of ellipses
+- use standard CSS syntax by default, and only swap parsers when testing a specific piece of non-standard syntax
+
+#### Commonly overlooked edge-cases
+
+You should ask yourself how does your rule handle:
+
+- variables (`$sass`, `@less` or `var(--custom-property)`)?
+- CSS strings (e.g. `content: "anything goes";`)?
+- CSS comments (e.g. `/* anything goes */`)?
+- `url()` functions, including data URIs (e.g. `url(anything/goes.jpg)`)?
+- vendor prefixes (e.g. `@-webkit-keyframes name {}`)?
+- case sensitivity (e.g. `@KEYFRAMES name {}`)?
+- a pseudo-class _combined_ with a pseudo-element (e.g. `a:hover::before`)?
+- nesting (e.g. do you resolve `& a {}`, or check it as is?)?
+- whitespace and punctuation (e.g. comparing `rgb(0,0,0)` with `rgb(0, 0, 0)`)?
+
+### Write the README
+
+You should:
+
+- only use standard CSS syntax in example code and options
+- use `<!-- prettier-ignore -->` before `css` code fences
+- use "this rule" to refer to the rule, e.g. "This rule ignores ..."
+- align the arrows within the prototypical code example with the beginning of the highlighted construct
+- align the text within the prototypical code example as far to the left as possible
+
+For example:
+
+<!-- prettier-ignore -->
+```css
+ @media screen and (min-width: 768px) {}
+/**                 ↑          ↑
+  *       These names and values */
+```
+
+When writing examples, you should use:
+
+- complete CSS patterns i.e. avoid ellipses (`...`)
+- the minimum amount of code possible to communicate the pattern, e.g. if the rule targets selectors then use an empty rule, e.g. `{}`
+- `{}`, rather than `{ }` for empty rules
+- the `a` type selector by default
+- the `@media` at-rules by default
+- the `color` property by default
+- _foo_, _bar_ and _baz_ for names, e.g. `.foo`, `#bar`, `--baz`
+
+Look at the READMEs of other rules to glean more conventional patterns.
+
+### Wire up the rule
+
+The final step is to add references to the new rule in the following places:
+
+- [The rules `index.js` file](../../lib/rules/index.js)
+- [The list of rules](../user-guide/rules/list.md)
+
+## Add an option to a rule
+
+You should:
+
+1. Get ready to [contribute code](../../CONTRIBUTING.md#code-contributions).
+2. Change the rule's validation to allow for the new option.
+3. Add new unit tests to test the option.
+4. Add (as little as possible) logic to the rule to make the tests pass.
+5. Add documentation about the new option.
+
+## Fix a bug in a rule
+
+You should:
+
+1. Get ready to [contribute code](../../CONTRIBUTING.md#code-contributions).
+2. Write failing unit tests that exemplify the bug.
+3. Fiddle with the rule until those new tests pass.
+
+## Deprecate a rule
+
+Deprecating rules doesn't happen very often. When you do, you must:
+
+1. Point the `stylelintReference` link to the specific version of the rule README on the GitHub website, so that it is always accessible.
+2. Add the appropriate meta data to mark the rule as deprecated.
+
+## Improve the performance of a rule
+
+You can run a benchmarks on any given rule with any valid config using:
+
+```shell
+npm run benchmark-rule -- ruleName ruleOptions [ruleContext]
+```
+
+If the `ruleOptions` 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 -- block-opening-brace-space-before "[\"always\", {\"ignoreAtRules\": [\"else\"]}]"
+```
+
+If the `ruleContext` argument is specified, the sames procedure would apply:
+
+```shell
+npm run benchmark-rule -- block-opening-brace-space-before "[\"always\", {\"ignoreAtRules\": [\"else\"]}]" "{\"fix\": \"true\"}"
+```
+
+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
+```
+
+When writing new rules or refactoring existing rules, use these measurements to determine the efficiency of your code.
+
+A stylelint rule can repeat its 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!
+
+**Improving the performance of a rule is a great way to contribute if you want a quick little project.** Try picking a rule and seeing if there's anything you can do to speed it up.
+
+Make sure you include benchmark measurements in your pull request!

node_modules/stylelint/docs/developer-guide/syntaxes.md

@@ -0,0 +1,35 @@
+# Working on syntaxes
+
+Please help us enhance and debug the [syntaxes](../about/syntaxes.md) we use in stylelint:
+
+- [postcss-css-in-js](https://github.com/stylelint/postcss-css-in-js)
+- [postcss-html](https://github.com/gucong3000/postcss-html)
+- [postcss-less](https://github.com/webschik/postcss-less)
+- [postcss-markdown](https://github.com/stylelint/postcss-markdown)
+- [postcss-sass](https://github.com/AleshaOleg/postcss-sass)
+- [postcss-scss](https://github.com/postcss/postcss-scss)
+
+To contribute to a syntax, you should:
+
+1. Familiarize yourself with PostCSS's [how to write custom syntax](https://github.com/postcss/postcss/blob/master/docs/syntax.md) guide.
+2. Use the [`syntax: *` labels](https://github.com/stylelint/stylelint/labels?utf8=%E2%9C%93&q=syntax%3A) to identify which syntax is behind an issue.
+3. Go to the repository for that syntax.
+4. Read their contributing guidelines.
+
+## Workarounds
+
+Fixing bugs in syntaxes can take time. stylelint can work around these bug by turning off autofix for incompatible sources. Autofix can then remain safe to use while contributors try to fix the underlying issue.
+
+### Current workarounds
+
+stylelint currently turns off autofix for sources that contain:
+
+- ~~nested tagged template literals ([issue #4119](https://github.com/stylelint/stylelint/issues/4119))~~
+
+### Add a workaround
+
+To add a new workaround, you should:
+
+1. Add code to [`lib/lintSource.js`](https://github.com/stylelint/stylelint/blob/master/lib/lintSource.js) to detect the incompatible pattern.
+2. Add a corresponding test to [`lib/__tests__/standalone-fix.test.js`](https://github.com/stylelint/stylelint/blob/master/lib/__tests__/standalone-fix.test.js).
+3. Document the workaround in [`docs/developer-guides/syntaxes.md`](https://github.com/stylelint/stylelint/blob/master/docs/developer-guide/syntaxes.md).

node_modules/stylelint/docs/developer-guide/system-tests.md

@@ -0,0 +1,23 @@
+# Writing system tests
+
+System tests verify that stylelint works as expected. They are another line of defense against regressions, after the unit tests and integration tests.
+
+Each of these system tests asserts that we end up with some expected output, given a configuration and a stylesheet.
+
+These tests should not be comprehensive and systematic (_the unit tests should_). They should reproduce real use-cases and verify that those use-cases work as expected.
+
+## Jest snapshots
+
+The tests use Jest snapshots, so we can easily:
+
+- assert against potentially large objects and strings
+- update expectations as needed.
+
+## The pattern
+
+To add a system test, you should:
+
+- add a test-case folder to `system-tests/` incrementing the number from existing test cases
+- add a configuration file and a stylesheet
+- add a `fs.test.js` and `no-fs.test.js` following the format established by existing tests, and using the `systemTestUtils`
+- take a snapshot of `output`

node_modules/stylelint/docs/maintainer-guide/issues.md

@@ -0,0 +1,94 @@
+# Managing issues
+
+We manage issues consistently for the benefit of ourselves and our users.
+
+## Labels
+
+Use [labels](https://github.com/stylelint/stylelint/labels).
+
+When you first triage an issue, you should:
+
+- add one of the `status: needs *` labels, e.g. `status: need discussion`
+- don't add any other label
+
+After triage, you should add:
+
+- _one_ of the non-need `status: *` labels, e.g. `status: ready to implement`
+- _zero or one_ of the `type: *` labels, e.g. `status: new rule`
+- _zero, one or more_ of the `syntax: *` labels, e.g. `syntax: scss`
+- optionally, the `good first issue`, `help wanted`, `priority: high` and `upstream` labels
+
+## Milestones
+
+Use [milestones](https://github.com/stylelint/stylelint/milestones).
+
+You should:
+
+- use the `future-major` milestone for issues that introduce breaking changes
+- optionally, create version milestones (e.g. `8.x`) to manage upcoming releases
+
+## Titles
+
+Rename the title into a consistent format.
+
+You should:
+
+- lead with the [CHANGELOG group names](pull-requests.md), but in the present tense:
+  - "Remove y", e.g. "Remove unit-disallowed-list"
+  - "Deprecate x in y", e.g. "Deprecate resolvedNested option in selector-class-pattern"
+  - "Add y", e.g. "Add unit-disallowed-list"
+  - "Add x to y", e.g. "Add ignoreProperties: [] to property-disallowed-list"
+  - "Fix false positives/negatives for x in y", e.g. "Fix false positives for Less mixins in color-no-hex"
+- use `*` if the issue applies to a group of rules, e.g. "Fix false negatives for SCSS variables in selector-\*-pattern"
+
+## Saved replies
+
+You should use [saved replies](https://help.github.com/en/github/writing-on-github/working-with-saved-replies).
+
+### Close an issue
+
+That doesn't use a template:
+
+```md
+Thank you for creating this issue. However, issues need to follow one of our templates so that we can clearly understand your particular circumstances.
+
+Please help us help you by [recreating the issue](https://github.com/stylelint/stylelint/issues/new/choose) using one of our templates.
+```
+
+That is best-suited as a plugin:
+
+```md
+Thank you for your suggestion. I think this is best-suited as a [plugin](https://stylelint.io/developer-guide/plugins).
+```
+
+### Label as ready to implement
+
+That fixes a bug in a rule:
+
+```md
+I've labeled the issue as ready to implement. Please consider [contributing](https://stylelint.io/contributing) if you have time.
+
+There are [steps on how to fix a bug in a rule](https://stylelint.io/developer-guide/rules#fix-a-bug-in-a-rule) in the Developer guide.
+```
+
+That adds a new option to a rule:
+
+```md
+I've labeled the issue as ready to implement. Please consider [contributing](https://stylelint.io/contributing) if you have time.
+
+There are [steps on how to add a new option](https://stylelint.io/developer-guide/rules#add-an-option-to-a-rule) in the Developer guide.
+```
+
+That adds a new rule:
+
+```md
+I've labeled the issue as ready to implement. Please consider [contributing](https://stylelint.io/contributing) if you have time.
+
+There are [steps on how to add a new rule](https://stylelint.io/developer-guide/rules#add-a-rule) in the Developer guide.
+```
+
+That is another type of improvement:
+
+```md
+I've labeled the issue as ready to implement. Please consider [contributing](https://stylelint.io/contributing) if you have time.
+```

node_modules/stylelint/docs/maintainer-guide/pull-requests.md

@@ -0,0 +1,33 @@
+# Managing pull requests
+
+You should:
+
+- use [GitHub reviews](https://help.github.com/articles/about-pull-request-reviews/)
+- review against the [Developer guide criteria](../developer-guide/rules.md)
+- resolve conflicts by [rebasing](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase)
+- assign _one or more_ [`pr: needs *`](https://github.com/stylelint/stylelint/labels) labels when requesting a change
+
+You should not use:
+
+- any other labels
+- any milestones
+
+## Merging
+
+To merge a pull request, it must have at least:
+
+- one approval for simple documentation fixes
+- two approvals for everything else
+
+When merging a PR, you should:
+
+1. ["Squash and merge"](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#squash-and-merge-your-pull-request-commits) commits and ensure the resulting commit message is:
+   - descriptive
+   - sentence case
+2. Update the [changelog](https://github.com/stylelint/stylelint/blob/master/CHANGELOG.md) directly via the [GitHub website](https://github.com/stylelint/stylelint/edit/master/CHANGELOG.md) for everything except refactoring and documentation changes:
+   1. Create a `## Head` heading if one does not exist already.
+   2. Prefix the item with either: "Removed", "Changed", "Deprecated", "Added", or "Fixed".
+   3. Order the item within the group by the widest-reaching first to the smallest, and then alphabetically by rule name.
+   4. Suffix the item with the relevant pull request number, using the complete GitHub URL so that it works on [the website](https://stylelint.io/CHANGELOG/).
+   5. If applicable, lead the item with the name of the rule, e.g. "Fixed: `unit-disallowed-list` false positives for SCSS nested properties".
+3. Post this update as a comment to the pull request.

node_modules/stylelint/docs/maintainer-guide/releases.md

@@ -0,0 +1,47 @@
+# Performing releases
+
+1. Create a [new issue](https://github.com/stylelint/stylelint/issues/new) announcing the planned release, e.g. `Release 8.11.1` and include the [template checklist](#new-release-issue-template).
+2. Locally test `master` in the `stylelint-config-*` shareable config repositories. Install current `master` branch (`npm install stylelint/stylelint#master`) and run tests.
+3. Locally test `master` in the [stylelint/stylelint.io](https://github.com/stylelint/stylelint.io) repository.
+4. Locally test `master` in the [stylelint/stylelint-demo](https://github.com/stylelint/stylelint-demo) repository.
+5. Publish the package to npm and create a GitHub release using [`np`](https://github.com/sindresorhus/np):
+   1. [Consistently format](pull-requests.md) the [changelog](../../CHANGELOG.md).
+   2. Replace `## Head` with new version number e.g. `## 8.1.2`.
+   3. Commit these changes.
+   4. Push these changes.
+   5. Confirm the changes are correct at [https://github.com/stylelint/stylelint](https://github.com/stylelint/stylelint).
+   6. Run `npm run release`.
+   7. Select the version that matches the one from the changelog.
+   8. Copy and paste the changelog entries for the published version from [changelog](../../CHANGELOG.md) when the GitHub release page opens.
+   9. Confirm the publishing of the package to [https://www.npmjs.com/package/stylelint](https://www.npmjs.com/package/stylelint).
+   10. Confirm the creation of the release at [https://github.com/stylelint/stylelint/releases](https://github.com/stylelint/stylelint/releases).
+6. If a new version of any `stylelint-config-*` is required, repeat step 5 for that repository.
+7. Update the online demo by changing to the `stylelint-demo` repository:
+   1. Run `npm install -S stylelint@latest`.
+   2. Run `npm test`.
+   3. Commit these changes.
+   4. Push these changes.
+   5. Confirm the deployment of the update to [stylelint.io/demo](https://stylelint.io/demo).
+8. Update the website documentation by changing to the `stylelint.io` repository:
+   1. Run `npm install -D stylelint@latest`.
+   2. Run `npm test`.
+   3. Commit these changes.
+   4. Push these changes.
+   5. Confirm the deployment of the update to [stylelint.io](https://stylelint.io).
+9. Compose a tweet that:
+   - announces the release
+   - communicates what has changed
+   - links to the appropriate heading in the changelog on [stylelint.io](https://stylelint.io).
+
+## New release issue template
+
+```markdown
+- [ ] stylelint release
+- [ ] stylelint-config-recommended update/release
+- [ ] stylelint-config-standard update/release
+- [ ] stylelint-demo update
+- [ ] stylelint.io update
+- [ ] tweet
+
+cc @stylelint/core
+```

node_modules/stylelint/docs/toc.md

@@ -0,0 +1,37 @@
+# Docs
+
+- User guide
+  - [Get started](user-guide/get-started.md)
+  - [Configuration](user-guide/configure.md)
+  - Rules
+    - [About](user-guide/rules/about.md)
+    - [Combine](user-guide/rules/combine.md)
+    - [Regex](user-guide/rules/regex.md)
+    - [List](user-guide/rules/list.md)
+  - Usage
+    - [CLI](user-guide/usage/cli.md)
+    - [Node.js API](user-guide/usage/node-api.md)
+    - [PostCSS plugin](user-guide/usage/postcss-plugin.md)
+    - [Options](user-guide/usage/options.md)
+  - Integrations
+    - [Editor](user-guide/integrations/editor.md)
+    - [Task runner](user-guide/integrations/task-runner.md)
+    - [Other](user-guide/integrations/other.md)
+  - [Ignore code](user-guide/ignore-code.md)
+  - [Errors](user-guide/errors.md)
+- Developer guide
+  - [Rules](developer-guide/rules.md)
+  - [Syntaxes](developer-guide/syntaxes.md)
+  - [Plugins](developer-guide/plugins.md)
+  - [Formatters](developer-guide/formatters.md)
+  - [System tests](developer-guide/system-tests.md)
+  - [Processors](developer-guide/processors.md)
+- Maintainer guide
+  - [Issues](maintainer-guide/issues.md)
+  - [Pull requests](maintainer-guide/pull-requests.md)
+  - [Releases](maintainer-guide/releases.md)
+- About
+  - [Linting](about/linting.md)
+  - [Syntaxes](about/syntaxes.md)
+  - [Semantic versioning](about/semantic-versioning.md)
+  - [Vision](about/vision.md)

node_modules/stylelint/docs/user-guide/configure.md

@@ -0,0 +1,420 @@
+# Configuration
+
+stylelint _expects a configuration object_.
+
+stylelint uses [cosmiconfig](https://github.com/davidtheclark/cosmiconfig) to find and load your configuration object. Starting from the current working directory, it looks for the following possible sources:
+
+- a `stylelint` property in `package.json`
+- a `.stylelintrc` file
+- a `stylelint.config.js` file exporting a JS object
+- a `stylelint.config.cjs` file exporting a JS object. When running stylelint in JavaScript packages that specify `"type":"module"` in their `package.json`
+
+The search stops when one of these is found, and stylelint uses that object. You can use the [`--config` or `configFile` option](usage/options.md#configfile) to short-circuit the search.
+
+The `.stylelintrc` file (without extension) can be in JSON or YAML format. You can add a filename extension to help your text editor provide syntax checking and highlighting:
+
+- `.stylelintrc.json`
+- `.stylelintrc.yaml` / `.stylelintrc.yml`
+- `.stylelintrc.js`
+
+The configuration object has the following properties:
+
+## `rules`
+
+Rules determine what the linter looks for and complains about. There are [over 170 rules](rules/list.md) built into stylelint.
+
+_No rules are turned on by default and there are no default values. You must explicitly configure each rule to turn it on._
+
+The `rules` property is _an object whose keys are rule names and values are rule configurations_. For example:
+
+```json
+{
+  "rules": {
+    "color-no-invalid-hex": true
+  }
+}
+```
+
+Each rule configuration fits one of the following formats:
+
+- `null` (to turn the rule off)
+- a single value (the primary option)
+- an array with two values (`[primary option, secondary options]`)
+
+Specifying a primary option turns on a rule.
+
+Many rules provide secondary options for further customization. To set secondary options, use a two-member array. For example:
+
+```json
+{
+  "rules": {
+    "selector-pseudo-class-no-unknown": [
+      true,
+      {
+        "ignorePseudoClasses": ["global"]
+      }
+    ]
+  }
+}
+```
+
+You can add any number of keys in the object. For example, you can:
+
+- turn off `block-no-empty`
+- turn on `comment-empty-line-before` with a primary and secondary option
+- turn on `max-empty-lines` and `unit-allowed-list` with primary options
+
+```json
+{
+  "rules": {
+    "block-no-empty": null,
+    "comment-empty-line-before": [
+      "always",
+      {
+        "ignore": ["stylelint-commands", "after-comment"]
+      }
+    ],
+    "max-empty-lines": 2,
+    "unit-allowed-list": ["em", "rem", "%", "s"]
+  }
+}
+```
+
+### `message`
+
+You can use the `message` secondary option to deliver a custom message when a rule is violated.
+
+For example, the following rule configuration would substitute in custom messages:
+
+```json
+{
+  "rules": {
+    "color-hex-case": [
+      "lower",
+      {
+        "message": "Lowercase letters are easier to distinguish from numbers"
+      }
+    ],
+    "indentation": [
+      2,
+      {
+        "except": ["block"],
+        "message": "Please use 2 spaces for indentation.",
+        "severity": "warning"
+      }
+    ]
+  }
+}
+```
+
+Alternately, you can write a [custom formatter](../developer-guide/formatters.md) for maximum control if you need serious customization.
+
+### `severity`
+
+You can use the `severity` secondary option to adjust any specific rule's severity.
+
+The available values for `severity` are:
+
+- `"warning"`
+- `"error"` (default)
+
+For example:
+
+```json
+{
+  "rules": {
+    "indentation": [
+      2,
+      {
+        "except": ["value"],
+        "severity": "warning"
+      }
+    ]
+  }
+}
+```
+
+Reporters may use these severity levels to display violations or exit the process differently.
+
+### `reportDisables`
+
+You can set the `reportDisables` secondary option to report any `stylelint-disable` comments for this rule, effectively disallowing authors to opt out of it.
+
+For example:
+
+```json
+{
+  "rules": {
+    "indentation": [
+      2,
+      {
+        "except": ["value"],
+        "reportDisables": true
+      }
+    ]
+  }
+}
+```
+
+The report is considered to be a lint error.
+
+## Disable Errors
+
+These configurations provide extra validation for `stylelint-disable` comments. This can be helpful for enforcing useful and well-documented disables.
+
+They are configured like rules. They can have one of three values:
+
+- `null` (to turn the configuration off)
+- `true` or `false` (the primary option)
+- an array with two values (`[primary option, secondary options]`)
+
+The following secondary options are available:
+
+- `"except"` takes an array of rule names for which the primary option should be inverted.
+- `"severity"` adjusts the level of error emitted for the rule, [as above](#severity).
+
+For example, this produces errors for needless disables of all rules except `selector-max-type`:
+
+```json
+{
+  "reportNeedlessDisables": [true, { "except": ["selector-max-type"] }]
+}
+```
+
+And this emits warnings for disables of `color-hex-case` that don't have a description:
+
+```json
+{
+  "reportDescriptionlessDisables": [
+    false,
+    {
+      "except": ["color-hex-case"],
+      "severity": "warning"
+    }
+  ]
+}
+```
+
+### `reportNeedlessDisables`
+
+Emit errors for `stylelint-disable` comments that don't actually match any lints that need to be disabled.
+
+For example:
+
+```json
+{
+  "reportNeedlessDisables": true
+}
+```
+
+### `reportInvalidScopeDisables`
+
+Emit errors for `stylelint-disable` comments that don't match rules that are specified in the configuration object.
+
+For example:
+
+```json
+{
+  "reportInvalidScopeDisables": true
+}
+```
+
+### `reportDescriptionlessDisables`
+
+Emit errors for `stylelint-disable` comments without a description.
+
+For example, when the configuration `{ block-no-empty: true }` is given, the following patterns are reported:
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable */
+a {}
+```
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable-next-line block-no-empty */
+a {}
+```
+
+But, the following patterns (`stylelint-disable -- <description>`) are _not_ reported:
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable -- This violation is ignorable. */
+a {}
+```
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable-next-line block-no-empty -- This violation is ignorable. */
+a {}
+```
+
+For example:
+
+```json
+{
+  "reportDescriptionlessDisables": true
+}
+```
+
+## `defaultSeverity`
+
+You can set the default severity level for all rules that do not have a severity specified in their secondary options. For example, you can set the default severity to `"warning"`:
+
+```json
+{
+  "defaultSeverity": "warning"
+}
+```
+
+## `ignoreDisables`
+
+Ignore `stylelint-disable` (e.g. `/* stylelint-disable block-no-empty */`) comments.
+
+For example:
+
+```json
+{
+  "ignoreDisables": true
+}
+```
+
+## `extends`
+
+You can _extend_ an existing configuration (whether your own or a third-party one).
+
+Popular configurations include:
+
+- [`stylelint-config-recommended`](https://github.com/stylelint/stylelint-config-recommended) - turns on just [possible error rules](rules/list.md#possible-errors)
+- [`stylelint-config-standard`](https://github.com/stylelint/stylelint-config-standard) - extends recommended one by turning on 60 [stylistic rules](rules/list.md#stylistic-issues)
+
+You'll find more in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#configs).
+
+When one configuration extends another, it starts with the other's properties then adds to and overrides what's there.
+
+For example, you can extend the [`stylelint-config-standard`](https://github.com/stylelint/stylelint-config-standard) and then change the indentation to tabs and turn off the `number-leading-zero` rule:
+
+```json
+{
+  "extends": "stylelint-config-standard",
+  "rules": {
+    "indentation": "tab",
+    "number-leading-zero": null
+  }
+}
+```
+
+You can extend an array of existing configurations, with each item in the array taking precedence over the previous item (so the second item overrides rules in the first, the third item overrides rules in the first and the second, and so on, the last item overrides everything else).
+
+For example, with `stylelint-config-standard`, then layer `myExtendableConfig` on top of that, and then override 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. It can fit whatever format works with Node's `require.resolve()` algorithm. That means 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.js 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).
+
+## `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.
+
+Popular plugin packs include:
+
+- [`stylelint-order`](https://github.com/hudochenkov/stylelint-order) - specify the ordering of things, e.g. properties within declaration blocks
+- [`stylelint-scss`](https://github.com/kristerkari/stylelint-scss) - enforce a wide variety of linting rules for SCSS-like syntax
+
+You'll find more in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#plugins).
+
+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 a:
+
+- npm module name
+- absolute path
+- 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. Look at the plugin's documentation to know what the rule name should be.
+
+```json
+{
+  "plugins": ["../special-rule.js"],
+  "rules": {
+    "plugin-namespace/special-rule": "everything"
+  }
+}
+```
+
+A "plugin" can provide a single rule or a set of rules. If the plugin you use provides a set, 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 built by the community that hook into stylelint's pipeline, modifying code on its way into stylelint and modifying results on their way out.
+
+**We discourage their use in favor of using the built-in [syntaxes](../about/syntaxes.md) as processors are incompatible with the [autofix feature](usage/options.md#fix).**
+
+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-my-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-my-processor",
+    ["some-other-processor", { "optionOne": true, "optionTwo": false }]
+  ],
+  "rules": {}
+}
+```
+
+Processors can also only be used with the CLI and the Node.js API, not with the PostCSS plugin. (The PostCSS plugin ignores them.)
+
+## `ignoreFiles`
+
+You can provide a glob or array of globs to ignore specific files.
+
+For example, you can ignore all JavaScript files:
+
+```json
+{
+  "ignoreFiles": ["**/*.js"]
+}
+```
+
+stylelint ignores the `node_modules` directory by default. However, this is overridden if `ignoreFiles` is set.
+
+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()`.
+
+The `ignoreFiles` property is stripped from extended configs: only the root-level config can ignore files.
+
+_Note that this is not an efficient method for ignoring lots of files._ If you want to ignore a lot of files efficiently, use [`.stylelintignore`](ignore-code.md) or adjust your files globs.

node_modules/stylelint/docs/user-guide/errors.md

@@ -0,0 +1,29 @@
+# Errors & warnings
+
+In addition to rule violations, stylelint surfaces the following errors and warnings:
+
+## CSS syntax error
+
+The chosen [PostCSS syntax](../about/syntaxes.md) was unable to parse the source.
+
+## Parse error
+
+The chosen [PostCSS syntax](../about/syntaxes.md) successfully parsed, but one of the construct-specific parsers failed to parse either a media query, selector or value within that source.
+
+The construct-specific parsers are:
+
+- `postcss-media-query-parser`
+- `postcss-selector-parser`
+- `postcss-value-parser`
+
+## Unknown rule error
+
+There is an unknown rule in the [configuration object](configure.md).
+
+## Deprecation warning
+
+There is a deprecated rule in the [configuration object](configure.md).
+
+## Invalid option warning
+
+There is a misconfigured rule in the [configuration object](configure.md).

node_modules/stylelint/docs/user-guide/get-started.md

@@ -0,0 +1,55 @@
+# Getting started
+
+1\. Use [npm](https://docs.npmjs.com/about-npm/) to install stylelint and its [`standard configuration`](https://github.com/stylelint/stylelint-config-standard):
+
+```shell
+npm install --save-dev stylelint stylelint-config-standard
+```
+
+2\. Create a `.stylelintrc.json` configuration file in the root of your project:
+
+```json
+{
+  "extends": "stylelint-config-standard"
+}
+```
+
+3\. Run stylelint on, for example, all the CSS files in your project:
+
+```shell
+npx stylelint "**/*.css"
+```
+
+This will lint your CSS for [possible errors](rules/list.md#possible-errors) and [stylistic issues](rules/list.md#stylistic-issues).
+
+## Customize
+
+Now that you're up and running, you'll likely want to customize stylelint to meet your needs.
+
+### Your configuration
+
+You'll want to customize your configuration.
+
+For example, you may want to use the popular:
+
+- [`stylelint-config-sass-guidelines` config](https://github.com/bjankord/stylelint-config-sass-guidelines) if you write SCSS
+- [`stylelint-order` plugin](https://github.com/hudochenkov/stylelint-order) if you want to order things like properties
+
+You'll find more [configs](https://github.com/stylelint/awesome-stylelint#configs) and [plugins](https://github.com/stylelint/awesome-stylelint#plugins) listed in [awesome stylelint](https://github.com/stylelint/awesome-stylelint).
+
+To further customize your stylelint configuration, you can adapt your:
+
+- [rules](configure.md#rules)
+- [shared configs](configure.md#extends)
+- [plugins](configure.md#plugins)
+
+We recommend you add [rules that limit language features](rules/list.md#limit-language-features) to your configuration, e.g. [`unit-allowed-list`](../../lib/rules/unit-allowed-list/README.md), [`selector-class-pattern`](../../lib/rules/selector-class-pattern/README.md) and [`selector-max-id`](../../lib/rules/selector-max-id/README.md). These are powerful rules that you can use to enforce non-stylistic consistency in your code.
+
+### Your usage
+
+You don't have to use the [Command Line Interface](usage/cli.md); you can also use the:
+
+- [Node API](usage/node-api.md)
+- [PostCSS plugin](usage/postcss-plugin.md)
+
+There are also integrations for [editors](integrations/editor.md), [task-runners](integrations/task-runner.md) and [others](integrations/other.md) too. Our [extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=stylelint.vscode-stylelint) is a popular choice that lets you see violations inline in your editor.

node_modules/stylelint/docs/user-guide/ignore-code.md

@@ -0,0 +1,88 @@
+# Ignoring code
+
+You can ignore:
+
+- within files
+- files entirely
+
+## Within files
+
+You can temporarily turn off rules using special comments in your CSS. For example, you can either turn all the rules off:
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable */
+a {}
+/* stylelint-enable */
+```
+
+Or you can turn off individual rules:
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable selector-no-id, declaration-no-important */
+#id {
+  color: pink !important;
+}
+/* stylelint-enable selector-no-id, declaration-no-important */
+```
+
+You can turn off rules for individual lines with a `/* stylelint-disable-line */` comment, after which you do not need to explicitly re-enable them:
+
+<!-- prettier-ignore -->
+```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:
+
+<!-- prettier-ignore -->
+```css
+#id {
+  /* stylelint-disable-next-line declaration-no-important */
+  color: pink !important;
+}
+```
+
+stylelint supports complex, overlapping disabling & enabling patterns:
+
+<!-- prettier-ignore -->
+```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.
+
+You may also include a description at the end of the comment, after two hyphens:
+
+```css
+/* stylelint-disable -- Reason for disabling stylelint. */
+/* stylelint-disable foo -- Reason for disabling the foo rule. */
+/* stylelint-disable foo, bar -- Reason for disabling the foo and bar rules. */
+```
+
+**Important:** There must be a space on both sides of the hyphens.
+
+## Files entirely
+
+You can use a `.stylelintignore` file to ignore specific files. For example:
+
+```
+**/*.js
+vendor/**/*.css
+```
+
+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.) _Your patterns in `.stylelintignore` are always analyzed relative to `process.cwd()`._
+
+stylelint looks 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.
+
+Alternatively, you can add an [`ignoreFiles` property](configure.md#ignorefiles) within your configuration object.

node_modules/stylelint/docs/user-guide/integrations/editor.md

@@ -0,0 +1,12 @@
+# Editor integrations
+
+Editor integrations built and maintained by the community.
+
+- [Ale](https://github.com/dense-analysis/ale) - Vim plugin that supports stylelint.
+- [Flycheck](https://github.com/flycheck/flycheck) - Emacs extension that supports stylelint.
+- [linter-stylelint](https://github.com/AtomLinter/linter-stylelint) - Atom plugin for stylelint.
+- [SublimeLinter-stylelint](https://github.com/SublimeLinter/SublimeLinter-stylelint) - Sublime Text plugin for stylelint.
+- [SublimeLinter-contrib-stylelint_d](https://github.com/jo-sm/SublimeLinter-contrib-stylelint_d) - Sublime Text plugin for stylelint that run's on daemon.
+- [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.
+- [vscode-stylelint](https://marketplace.visualstudio.com/items?itemName=stylelint.vscode-stylelint) - VS Code extension for stylelint.
+- [coc-stylelint](https://github.com/neoclide/coc-stylelint) - coc.nvim language server extension for neovim.

node_modules/stylelint/docs/user-guide/integrations/other.md

@@ -0,0 +1,19 @@
+# Other integrations
+
+Other integrations built and maintained by the community.
+
+## Analysis platform engines
+
+- [codacy-stylelint](https://github.com/codacy/codacy-stylelint) - [Codacy](https://www.codacy.com/) engine for stylelint
+- [codeclimate-stylelint](https://github.com/gilbarbara/codeclimate-stylelint) - Code Climate engine for stylelint
+- [Mega-Linter](https://nvuillam.github.io/mega-linter) - 70+ linters for any type of projects, usable in CI or locally, embedding [stylelint](https://nvuillam.github.io/mega-linter/descriptors/css_stylelint/) in default configuration
+- [reviewdog/action-stylelint](https://github.com/reviewdog/action-stylelint) - GitHub Action to run stylelint with [reviewdog](https://github.com/reviewdog/reviewdog)
+
+## Version Control
+
+- [Pre-commit](https://github.com/awebdeveloper/pre-commit-stylelint) - Git pre-commit hook for stylelint
+
+## Command Line Tools
+
+- [stylelint-find-rules](https://github.com/alexilyaev/stylelint-find-rules) - find Stylelint rules that you don't have in your config.
+- [putout](https://github.com/coderaiser/putout) - pluggable and configurable code transformer.

node_modules/stylelint/docs/user-guide/integrations/task-runner.md

@@ -0,0 +1,10 @@
+# Task runner integrations
+
+Task runner integrations built and maintained by the community.
+
+- [broccoli-stylelint](https://github.com/billybonks/broccoli-stylelint) - Broccoli plugin for stylelint.
+- [ember-cli-stylelint](https://github.com/billybonks/ember-cli-stylelint) - Ember CLI plugin for stylelint.
+- [grunt-stylelint](https://github.com/wikimedia/grunt-stylelint) - Grunt plugin for stylelint.
+- [gulp-stylelint](https://github.com/olegskl/gulp-stylelint) - gulp plugin for stylelint.
+- [jest-runner-stylelint](https://github.com/keplersj/jest-runner-stylelint) - Jest plugin for stylelint.
+- [stylelint-webpack-plugin](https://github.com/webpack-contrib/stylelint-webpack-plugin) - webpack plugin for stylelint.

node_modules/stylelint/docs/user-guide/rules/about.md

@@ -0,0 +1,203 @@
+# About rules
+
+The built-in rules:
+
+- apply to standard CSS syntax only
+- are generally useful; not tied to idiosyncratic patterns
+- have a clear and unambiguous finished state
+- have a singular purpose
+- are standalone, and don't rely on another rule
+- do not contain functionality that overlaps with another rule
+
+In contrast, a plugin is a community rule that doesn't adhere to all these criteria. It might support a particular methodology or toolset, or apply to _non-standard_ constructs and features, or be for specific use cases.
+
+## Options
+
+Each rule accepts a primary and an optional secondary option.
+
+### Primary
+
+Every rule _must have_ a primary option. For example, in:
+
+- `"color-hex-case": "upper"`, the primary option is `"upper"`
+- `"indentation": [2, { "except": ["block"] }]`, the primary option is `2`
+
+### Secondary
+
+Some rules require extra flexibility to address edge cases. These can use an optional secondary options object. For example, in:
+
+- `"color-hex-case": "upper"` there is no secondary options object
+- `"indentation": [2, { "except": ["block"] }]`, the secondary options object is `{ "except": ["block"] }`
+
+The most typical secondary options are `"ignore": []` and `"except": []`.
+
+#### Keyword `"ignore"` and `"except"`
+
+The `"ignore"` and `"except"` options accept an array of predefined keyword options, e.g. `["relative", "first-nested", "descendant"]`:
+
+- `"ignore"` skips-over a particular pattern
+- `"except"` inverts the primary option for a particular pattern
+
+#### User-defined `"ignore*"`
+
+Some rules accept a _user-defined_ list of things to ignore. This takes the form of `"ignore<Things>": []`, e.g. `"ignoreAtRules": []`.
+
+The `ignore*` options let users ignore non-standard syntax at the _configuration level_. For example, the:
+
+- `:global` and `:local` pseudo-classes introduced in CSS Modules
+- `@debug` and `@extend` at-rules introduced in SCSS
+
+Methodologies and language extensions come and go quickly, and this approach ensures our codebase does not become littered with code for obsolete things.
+
+## Names
+
+Rule are consistently named, they are:
+
+- made up of lowercase words separated by hyphens
+- split into two parts
+
+The first part describes what [_thing_](http://apps.workflower.fi/vocabs/css/en) the rule applies to. The second part describes what the rule is checking.
+
+For example:
+
+```
+"number-leading-zero"
+// ↑          ↑
+// the thing  what the rule is checking
+```
+
+There is no first part when the rule applies to the whole stylesheet.
+
+For example:
+
+```
+"no-eol-whitespace"
+"indentation"
+//    ↑
+// what the rules are checking
+```
+
+_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_.
+
+### No rules
+
+Most rules 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
+
+<!-- prettier-ignore -->
+```css
+a { line-height: 0.5; }
+/**              ↑
+ * This leading zero */
+```
+
+However, some rules _just disallow_ something. These rules include `*-no-*` in their name.
+
+For example, to disallow empty blocks:
+
+- `block-no-empty` - blocks _must not_ be empty
+
+<!-- prettier-ignore -->
+```css
+a {   }
+/** ↑
+ * Blocks like this */
+```
+
+Notice how it does not make sense to have an option to enforce the opposite, i.e. that every block _must_ be empty.
+
+### Max and min rules
+
+`*-max-*` and `*-min-*` rules _set a limit_ to something.
+
+For example, specifying the maximum number of digits after the "." in a number:
+
+- `number-max-precision`: `int`
+
+<!-- prettier-ignore -->
+```css
+a { font-size: 1.333em; }
+/**             ↑
+ * The maximum number of digits after this "." */
+```
+
+### Whitespace rules
+
+Whitespace rules allow you to enforce an empty line, a single space, a newline or no space in some specific part of the stylesheet.
+
+The whitespace rules combine two sets of keywords:
+
+- `before`, `after` and `inside` to specify where the whitespace (if any) is expected
+- `empty-line`, `space` and `newline` 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"`
+
+<!-- prettier-ignore -->
+```css
+a {}
+              ←
+/* comment */ ↑
+              ↑
+/**           ↑
+ * This empty line  */
+```
+
+Additionally, some whitespace rules use an additional set of keywords:
+
+- `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 targeted
+
+For example, specifying if a single space or no space must follow a comma in a function:
+
+- `function-comma-space-after`: `string` - `"always"|"never"`
+
+<!-- prettier-ignore -->
+```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"`
+
+<!-- prettier-ignore -->
+```css
+a { transform: translate( 1, 1 ); }
+/**                     ↑      ↑
+ * The space inside these two parentheses */
+```
+
+## READMEs
+
+Each rule is accompanied by a README in 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 violations (for each option value).
+7. Example patterns that are _not_ considered violations (for each option value).
+8. Optional options (if applicable).
+
+The single-line description is in the form of:
+
+- "Disallow ..." for `no` rules
+- "Limit ..." for `max` rules
+- "Require ..." for rules that accept `"always"` and `"never"` options
+- "Specify ..." for everything else
+
+## Violation messages
+
+Each rule produces violation messages in these forms:
+
+- "Expected \[something\] \[in some context\]"
+- "Unexpected \[something\] \[in some context\]"

node_modules/stylelint/docs/user-guide/rules/combine.md

@@ -0,0 +1,360 @@
+# Combining rules
+
+You can combine rules 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:
+
+<!-- prettier-ignore -->
+```css
+a { color: pink; }
+/**      ↑
+ * No space before and a single space after this colon */
+```
+
+You can enforce that with:
+
+```json
+{
+  "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:
+
+<!-- prettier-ignore -->
+```css
+a,
+b {
+  color: red;
+  font-family: sans, serif, monospace; /* single-line value list */
+}              ↑                    ↑
+/**            ↑                    ↑
+ *  The value list starts 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. The `*-multi-line` and `*-single-line` refer to the value list 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:
+
+<!-- prettier-ignore -->
+```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:
+
+```json
+{
+  "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:
+
+<!-- prettier-ignore -->
+```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:
+
+```json
+{
+  "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:
+
+<!-- prettier-ignore -->
+```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:
+
+```json
+{
+  "value-list-comma-newline-before": "always-multi-line",
+  "value-list-comma-space-after": "always",
+  "value-list-comma-space-before": "never-single-line"
+}
+```
+
+### Example D
+
+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:
+
+<!-- prettier-ignore -->
+```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:
+
+```json
+{
+  "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"
+}
+```
+
+### Example E
+
+Say you want to disable single-line blocks:
+
+<!-- prettier-ignore -->
+```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:
+
+<!-- prettier-ignore -->
+```css
+a {
+  color: red;
+}
+```
+
+But not these patterns:
+
+<!-- prettier-ignore -->
+```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.
+
+## `*-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:
+
+<!-- prettier-ignore -->
+```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:
+
+```json
+{
+  "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-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 sets 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:
+
+<!-- prettier-ignore -->
+```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:
+
+```json
+{
+  "function-max-empty-lines": 0,
+  "max-empty-lines": 1,
+  "selector-list-max-empty-lines": 0,
+  "value-list-max-empty-lines": 0
+}
+```
+
+## `*-allowed-list`, `*-disallowed-list`, `color-named` and applicable `*-no-*` rules
+
+These rules work together to (dis)allow language features and constructs.
+
+There are `*-allowed-list` and `*-disallowed-list` rules that target the constructs of the CSS language: at-rules, functions, declarations (i.e. property-value pairs), properties and units. These rules (dis)allow any language features that make use of these constructs (e.g. `@media`, `rgb()`). However, there are features not caught by these `*-allowed-list` and `*-disallowed-list` 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-disallowed-list` or `at-rule-allowed-list` rules because the `@debug` language extension uses the at-rule construct e.g.
+
+```json
+{
+  "at-rule-disallowed-list": ["debug"]
+}
+```
+
+Say you want to, for whatever reason, disallow the whole at-rule construct. You can do that using:
+
+```json
+{
+  "at-rule-allowed-list": []
+}
+```
+
+Say you want to disallow the value `none` for the `border` properties. You can do that using either the `declaration-property-value-disallowed-list` or `declaration-property-value-allowed-list` e.g.
+
+```json
+{
+  "declaration-property-value-disallowed-list": [
+    {
+      "/^border/": ["none"]
+    }
+  ]
+}
+```
+
+## `color-*` and `function-*` rules
+
+Most `<color>` values are _functions_. As such, they can be (dis)allowed using either the `function-allowed-list` or `function-disallowed-list` rules. Two other color representations 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.:
+
+<!-- prettier-ignore -->
+```css
+a {
+  background: hwb(235, 0%, 0%); /* there is no named color equivalent for this color */
+  color: black;
+}
+```
+
+If you're taking an allow approach, you can do that with:
+
+```json
+{
+  "color-named": "always-where-possible",
+  "color-no-hex": true,
+  "function-allowed-list": ["hwb"]
+}
+```
+
+Or, if you're taking a disallow approach:
+
+```json
+{
+  "color-named": "always-where-possible",
+  "color-no-hex": true,
+  "function-disallowed-list": ["/^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:
+
+```json
+{
+  "color-named": "never",
+  "color-no-hex": true,
+  "function-allowed-list": ["my-color"]
+}
+```
+
+## Manage conflicts
+
+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 allow and disallow list rules, e.g. `unit-allowed-list` and `unit-disallowed-list`.
+
+It's your responsibility as the configuration author to resolve these conflicts.

node_modules/stylelint/docs/user-guide/rules/list.md

@@ -0,0 +1,399 @@
+# List of rules
+
+Grouped first by the following categories and then by the [_thing_](http://apps.workflower.fi/vocabs/css/en) they apply to.
+
+- [Possible errors](#possible-errors)
+- [Limit language features](#limit-language-features)
+- [Stylistic issues](#stylistic-issues)
+
+## Possible errors
+
+### Color
+
+- [`color-no-invalid-hex`](../../../lib/rules/color-no-invalid-hex/README.md): Disallow invalid hex colors.
+
+### Font family
+
+- [`font-family-no-duplicate-names`](../../../lib/rules/font-family-no-duplicate-names/README.md): Disallow duplicate font family names.
+- [`font-family-no-missing-generic-family-keyword`](../../../lib/rules/font-family-no-missing-generic-family-keyword/README.md): Disallow missing generic families in lists of font family names.
+
+### Named grid areas
+
+- [`named-grid-areas-no-invalid`](../../../lib/rules/named-grid-areas-no-invalid/README.md): Disallow invalid named grid areas.
+
+### Function
+
+- [`function-calc-no-invalid`](../../../lib/rules/function-calc-no-invalid/README.md): Disallow an invalid expression within `calc` functions.
+- [`function-calc-no-unspaced-operator`](../../../lib/rules/function-calc-no-unspaced-operator/README.md): Disallow an unspaced operator within `calc` 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).
+
+### String
+
+- [`string-no-newline`](../../../lib/rules/string-no-newline/README.md): Disallow (unescaped) newlines in strings.
+
+### Unit
+
+- [`unit-no-unknown`](../../../lib/rules/unit-no-unknown/README.md): Disallow unknown units.
+
+### Property
+
+- [`property-no-unknown`](../../../lib/rules/property-no-unknown/README.md): Disallow unknown properties.
+
+### Keyframe declaration
+
+- [`keyframe-declaration-no-important`](../../../lib/rules/keyframe-declaration-no-important/README.md): Disallow `!important` within keyframe declarations.
+
+### Declaration block
+
+- [`declaration-block-no-duplicate-custom-properties`](../../../lib/rules/declaration-block-no-duplicate-custom-properties/README.md): Disallow duplicate custom properties within declaration blocks.
+- [`declaration-block-no-duplicate-properties`](../../../lib/rules/declaration-block-no-duplicate-properties/README.md): Disallow duplicate properties within declaration blocks.
+- [`declaration-block-no-shorthand-property-overrides`](../../../lib/rules/declaration-block-no-shorthand-property-overrides/README.md): Disallow shorthand properties that override related longhand properties.
+
+### Block
+
+- [`block-no-empty`](../../../lib/rules/block-no-empty/README.md): Disallow empty blocks.
+
+### Selector
+
+- [`selector-pseudo-class-no-unknown`](../../../lib/rules/selector-pseudo-class-no-unknown/README.md): Disallow unknown pseudo-class selectors.
+- [`selector-pseudo-element-no-unknown`](../../../lib/rules/selector-pseudo-element-no-unknown/README.md): Disallow unknown pseudo-element selectors.
+- [`selector-type-no-unknown`](../../../lib/rules/selector-type-no-unknown/README.md): Disallow unknown type selectors.
+
+### Media feature
+
+- [`media-feature-name-no-unknown`](../../../lib/rules/media-feature-name-no-unknown/README.md): Disallow unknown media feature names.
+
+### At-rule
+
+- [`at-rule-no-unknown`](../../../lib/rules/at-rule-no-unknown/README.md): Disallow unknown at-rules.
+
+### Comment
+
+- [`comment-no-empty`](../../../lib/rules/comment-no-empty/README.md): Disallow empty comments.
+
+### General / Sheet
+
+- [`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-at-import-rules`](../../../lib/rules/no-duplicate-at-import-rules/README.md): Disallow duplicate `@import` rules within a stylesheet.
+- [`no-duplicate-selectors`](../../../lib/rules/no-duplicate-selectors/README.md): Disallow duplicate selectors within a stylesheet.
+- [`no-empty-source`](../../../lib/rules/no-empty-source/README.md): Disallow empty sources.
+- [`no-extra-semicolons`](../../../lib/rules/no-extra-semicolons/README.md): Disallow extra semicolons (Autofixable).
+- [`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-invalid-position-at-import-rule`](../../../lib/rules/no-invalid-position-at-import-rule/README.md): Disallow invalid position `@import` rules within a stylesheet.
+
+## Limit language features
+
+### Alpha-value
+
+- [`alpha-value-notation`](../../../lib/rules/alpha-value-notation/README.md): Specify percentage or number notation for alpha-values (Autofixable).
+
+### Hue
+
+- [`hue-degree-notation`](../../../lib/rules/hue-degree-notation/README.md): Specify number or angle notation for degree hues (Autofixable).
+
+### Color
+
+- [`color-function-notation`](../../../lib/rules/color-function-notation/README.md): Specify modern or legacy notation for applicable color-functions (Autofixable).
+- [`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.
+
+### Length
+
+- [`length-zero-no-unit`](../../../lib/rules/length-zero-no-unit/README.md): Disallow units for zero lengths (Autofixable).
+
+### Font weight
+
+- [`font-weight-notation`](../../../lib/rules/font-weight-notation/README.md): Require numeric or named (where possible) `font-weight` values. Also, when named values are expected, require only valid names.
+
+### Function
+
+- [`function-allowed-list`](../../../lib/rules/function-allowed-list/README.md): Specify a list of allowed functions.
+- [`function-blacklist`](../../../lib/rules/function-blacklist/README.md): Specify a list of disallowed functions. **(deprecated)**
+- [`function-disallowed-list`](../../../lib/rules/function-disallowed-list/README.md): Specify a list of disallowed functions.
+- [`function-url-no-scheme-relative`](../../../lib/rules/function-url-no-scheme-relative/README.md): Disallow scheme-relative urls.
+- [`function-url-scheme-allowed-list`](../../../lib/rules/function-url-scheme-allowed-list/README.md): Specify a list of allowed URL schemes.
+- [`function-url-scheme-blacklist`](../../../lib/rules/function-url-scheme-blacklist/README.md): Specify a list of disallowed URL schemes. **(deprecated)**
+- [`function-url-scheme-disallowed-list`](../../../lib/rules/function-url-scheme-disallowed-list/README.md): Specify a list of disallowed URL schemes.
+- [`function-url-scheme-whitelist`](../../../lib/rules/function-url-scheme-whitelist/README.md): Specify a list of allowed URL schemes. **(deprecated)**
+- [`function-whitelist`](../../../lib/rules/function-whitelist/README.md): Specify a list of allowed functions. **(deprecated)**
+
+### Keyframes
+
+- [`keyframes-name-pattern`](../../../lib/rules/keyframes-name-pattern/README.md): Specify a pattern for keyframe names.
+
+### Number
+
+- [`number-max-precision`](../../../lib/rules/number-max-precision/README.md): Limit the number of decimal places allowed in numbers.
+
+### Time
+
+- [`time-min-milliseconds`](../../../lib/rules/time-min-milliseconds/README.md): Specify the minimum number of milliseconds for time values.
+
+### Unit
+
+- [`unit-allowed-list`](../../../lib/rules/unit-allowed-list/README.md): Specify a list of allowed units.
+- [`unit-blacklist`](../../../lib/rules/unit-blacklist/README.md): Specify a list of disallowed units. **(deprecated)**
+- [`unit-disallowed-list`](../../../lib/rules/unit-disallowed-list/README.md): Specify a list of disallowed units.
+- [`unit-whitelist`](../../../lib/rules/unit-whitelist/README.md): Specify a list of allowed units. **(deprecated)**
+
+### Shorthand property
+
+- [`shorthand-property-no-redundant-values`](../../../lib/rules/shorthand-property-no-redundant-values/README.md): Disallow redundant values in shorthand properties (Autofixable).
+
+### Value
+
+- [`value-no-vendor-prefix`](../../../lib/rules/value-no-vendor-prefix/README.md): Disallow vendor prefixes for values (Autofixable).
+
+### Custom property
+
+- [`custom-property-pattern`](../../../lib/rules/custom-property-pattern/README.md): Specify a pattern for custom properties.
+
+### Property
+
+- [`property-allowed-list`](../../../lib/rules/property-allowed-list/README.md): Specify a list of allowed properties.
+- [`property-blacklist`](../../../lib/rules/property-blacklist/README.md): Specify a list of disallowed properties. **(deprecated)**
+- [`property-disallowed-list`](../../../lib/rules/property-disallowed-list/README.md): Specify a list of disallowed properties.
+- [`property-no-vendor-prefix`](../../../lib/rules/property-no-vendor-prefix/README.md): Disallow vendor prefixes for properties (Autofixable).
+- [`property-whitelist`](../../../lib/rules/property-whitelist/README.md): Specify a list of allowed properties. **(deprecated)**
+
+### Declaration
+
+- [`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-no-important`](../../../lib/rules/declaration-no-important/README.md): Disallow `!important` within declarations.
+- [`declaration-property-unit-allowed-list`](../../../lib/rules/declaration-property-unit-allowed-list/README.md): Specify a list of allowed property and unit pairs within declarations.
+- [`declaration-property-unit-blacklist`](../../../lib/rules/declaration-property-unit-blacklist/README.md): Specify a list of disallowed property and unit pairs within declarations. **(deprecated)**
+- [`declaration-property-unit-disallowed-list`](../../../lib/rules/declaration-property-unit-disallowed-list/README.md): Specify a list of disallowed property and unit pairs within declarations.
+- [`declaration-property-unit-whitelist`](../../../lib/rules/declaration-property-unit-whitelist/README.md): Specify a list of allowed property and unit pairs within declarations. **(deprecated)**
+- [`declaration-property-value-allowed-list`](../../../lib/rules/declaration-property-value-allowed-list/README.md): Specify a list of allowed property and value pairs within declarations.
+- [`declaration-property-value-blacklist`](../../../lib/rules/declaration-property-value-blacklist/README.md): Specify a list of disallowed property and value pairs within declarations. **(deprecated)**
+- [`declaration-property-value-disallowed-list`](../../../lib/rules/declaration-property-value-disallowed-list/README.md): Specify a list of disallowed property and value pairs within declarations.
+- [`declaration-property-value-whitelist`](../../../lib/rules/declaration-property-value-whitelist/README.md): Specify a list of allowed property and value pairs within declarations. **(deprecated)**
+
+### Declaration block
+
+- [`declaration-block-single-line-max-declarations`](../../../lib/rules/declaration-block-single-line-max-declarations/README.md): Limit the number of declarations within a single-line declaration block.
+
+### Selector
+
+- [`selector-attribute-name-disallowed-list`](../../../lib/rules/selector-attribute-name-disallowed-list/README.md): Specify a list of disallowed attribute names.
+- [`selector-attribute-operator-allowed-list`](../../../lib/rules/selector-attribute-operator-allowed-list/README.md): Specify a list of allowed attribute operators.
+- [`selector-attribute-operator-blacklist`](../../../lib/rules/selector-attribute-operator-blacklist/README.md): Specify a list of disallowed attribute operators. **(deprecated)**
+- [`selector-attribute-operator-disallowed-list`](../../../lib/rules/selector-attribute-operator-disallowed-list/README.md): Specify a list of disallowed attribute operators.
+- [`selector-attribute-operator-whitelist`](../../../lib/rules/selector-attribute-operator-whitelist/README.md): Specify a list of allowed attribute operators. **(deprecated)**
+- [`selector-class-pattern`](../../../lib/rules/selector-class-pattern/README.md): Specify a pattern for class selectors.
+- [`selector-combinator-allowed-list`](../../../lib/rules/selector-combinator-allowed-list/README.md): Specify a list of allowed combinators.
+- [`selector-combinator-blacklist`](../../../lib/rules/selector-combinator-blacklist/README.md): Specify a list of disallowed combinators. **(deprecated)**
+- [`selector-combinator-disallowed-list`](../../../lib/rules/selector-combinator-disallowed-list/README.md): Specify a list of disallowed combinators.
+- [`selector-combinator-whitelist`](../../../lib/rules/selector-combinator-whitelist/README.md): Specify a list of allowed combinators. **(deprecated)**
+- [`selector-disallowed-list`](../../../lib/rules/selector-disallowed-list/README.md): Specify a list of disallowed selectors.
+- [`selector-id-pattern`](../../../lib/rules/selector-id-pattern/README.md): Specify a pattern for ID selectors.
+- [`selector-max-attribute`](../../../lib/rules/selector-max-attribute/README.md): Limit the number of attribute selectors in a selector.
+- [`selector-max-class`](../../../lib/rules/selector-max-class/README.md): Limit the number of classes in a selector.
+- [`selector-max-combinators`](../../../lib/rules/selector-max-combinators/README.md): Limit the number of combinators in a selector.
+- [`selector-max-compound-selectors`](../../../lib/rules/selector-max-compound-selectors/README.md): Limit the number of compound selectors in a selector.
+- [`selector-max-empty-lines`](../../../lib/rules/selector-max-empty-lines/README.md): Limit the number of adjacent empty lines within selectors (Autofixable).
+- [`selector-max-id`](../../../lib/rules/selector-max-id/README.md): Limit the number of ID selectors in a selector.
+- [`selector-max-pseudo-class`](../../../lib/rules/selector-max-pseudo-class/README.md): Limit the number of pseudo-classes in a selector.
+- [`selector-max-specificity`](../../../lib/rules/selector-max-specificity/README.md): Limit the specificity of selectors.
+- [`selector-max-type`](../../../lib/rules/selector-max-type/README.md): Limit the number of type in a selector.
+- [`selector-max-universal`](../../../lib/rules/selector-max-universal/README.md): Limit the number of universal selectors in a selector.
+- [`selector-nested-pattern`](../../../lib/rules/selector-nested-pattern/README.md): Specify a pattern for the selectors of rules nested within rules.
+- [`selector-no-qualifying-type`](../../../lib/rules/selector-no-qualifying-type/README.md): Disallow qualifying a selector by type.
+- [`selector-no-vendor-prefix`](../../../lib/rules/selector-no-vendor-prefix/README.md): Disallow vendor prefixes for selectors (Autofixable).
+- [`selector-pseudo-class-allowed-list`](../../../lib/rules/selector-pseudo-class-allowed-list/README.md): Specify a list of allowed pseudo-class selectors.
+- [`selector-pseudo-class-blacklist`](../../../lib/rules/selector-pseudo-class-blacklist/README.md): Specify a list of disallowed pseudo-class selectors. **(deprecated)**
+- [`selector-pseudo-class-disallowed-list`](../../../lib/rules/selector-pseudo-class-disallowed-list/README.md): Specify a list of disallowed pseudo-class selectors.
+- [`selector-pseudo-class-whitelist`](../../../lib/rules/selector-pseudo-class-whitelist/README.md): Specify a list of allowed pseudo-class selectors. **(deprecated)**
+- [`selector-pseudo-element-allowed-list`](../../../lib/rules/selector-pseudo-element-allowed-list/README.md): Specify a list of allowed pseudo-element selectors.
+- [`selector-pseudo-element-blacklist`](../../../lib/rules/selector-pseudo-element-blacklist/README.md): Specify a list of disallowed pseudo-element selectors. **(deprecated)**
+- [`selector-pseudo-element-colon-notation`](../../../lib/rules/selector-pseudo-element-colon-notation/README.md): Specify single or double colon notation for applicable pseudo-elements (Autofixable).
+- [`selector-pseudo-element-disallowed-list`](../../../lib/rules/selector-pseudo-element-disallowed-list/README.md): Specify a list of disallowed pseudo-element selectors.
+- [`selector-pseudo-element-whitelist`](../../../lib/rules/selector-pseudo-element-whitelist/README.md): Specify a list of allowed pseudo-element selectors. **(deprecated)**
+
+### Media feature
+
+- [`media-feature-name-allowed-list`](../../../lib/rules/media-feature-name-allowed-list/README.md): Specify a list of allowed media feature names.
+- [`media-feature-name-blacklist`](../../../lib/rules/media-feature-name-blacklist/README.md): Specify a list of disallowed media feature names. **(deprecated)**
+- [`media-feature-name-disallowed-list`](../../../lib/rules/media-feature-name-disallowed-list/README.md): Specify a list of disallowed 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 (Autofixable).
+- [`media-feature-name-value-allowed-list`](../../../lib/rules/media-feature-name-value-allowed-list/README.md): Specify a list of allowed media feature name and value pairs.
+- [`media-feature-name-value-whitelist`](../../../lib/rules/media-feature-name-value-whitelist/README.md): Specify a list of allowed media feature name and value pairs. **(deprecated)**
+- [`media-feature-name-whitelist`](../../../lib/rules/media-feature-name-whitelist/README.md): Specify a list of allowed media feature names. **(deprecated)**
+
+### Custom media
+
+- [`custom-media-pattern`](../../../lib/rules/custom-media-pattern/README.md): Specify a pattern for custom media query names.
+
+### At-rule
+
+- [`at-rule-allowed-list`](../../../lib/rules/at-rule-allowed-list/README.md): Specify a list of allowed at-rules.
+- [`at-rule-blacklist`](../../../lib/rules/at-rule-blacklist/README.md): Specify a list of disallowed at-rules. **(deprecated)**
+- [`at-rule-disallowed-list`](../../../lib/rules/at-rule-disallowed-list/README.md): Specify a list of disallowed at-rules.
+- [`at-rule-no-vendor-prefix`](../../../lib/rules/at-rule-no-vendor-prefix/README.md): Disallow vendor prefixes for at-rules (Autofixable).
+- [`at-rule-property-required-list`](../../../lib/rules/at-rule-property-required-list/README.md): Specify a list of required properties for an at-rule.
+- [`at-rule-property-requirelist`](../../../lib/rules/at-rule-property-requirelist/README.md): Specify a list of required properties for an at-rule. **(deprecated)**
+- [`at-rule-whitelist`](../../../lib/rules/at-rule-whitelist/README.md): Specify a list of allowed at-rules. **(deprecated)**
+
+### Comment
+
+- [`comment-pattern`](../../../lib/rules/comment-pattern/README.md): Specify a pattern for comments.
+- [`comment-word-blacklist`](../../../lib/rules/comment-word-blacklist/README.md): Specify a list of disallowed words within comments. **(deprecated)**
+- [`comment-word-disallowed-list`](../../../lib/rules/comment-word-disallowed-list/README.md): Specify a list of disallowed words within comments.
+
+### General / Sheet
+
+- [`max-nesting-depth`](../../../lib/rules/max-nesting-depth/README.md): Limit the depth of nesting.
+- [`no-unknown-animations`](../../../lib/rules/no-unknown-animations/README.md): Disallow unknown animations.
+
+## Stylistic issues
+
+### Color
+
+- [`color-hex-case`](../../../lib/rules/color-hex-case/README.md): Specify lowercase or uppercase for hex colors (Autofixable).
+- [`color-hex-length`](../../../lib/rules/color-hex-length/README.md): Specify short or long notation for hex colors (Autofixable).
+
+### 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.
+
+### Function
+
+- [`function-comma-newline-after`](../../../lib/rules/function-comma-newline-after/README.md): Require a newline or disallow whitespace after the commas of functions (Autofixable).
+- [`function-comma-newline-before`](../../../lib/rules/function-comma-newline-before/README.md): Require a newline or disallow whitespace before the commas of functions (Autofixable).
+- [`function-comma-space-after`](../../../lib/rules/function-comma-space-after/README.md): Require a single space or disallow whitespace after the commas of functions (Autofixable).
+- [`function-comma-space-before`](../../../lib/rules/function-comma-space-before/README.md): Require a single space or disallow whitespace before the commas of functions (Autofixable).
+- [`function-max-empty-lines`](../../../lib/rules/function-max-empty-lines/README.md): Limit the number of adjacent empty lines within functions (Autofixable).
+- [`function-name-case`](../../../lib/rules/function-name-case/README.md): Specify lowercase or uppercase for function names (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`function-url-quotes`](../../../lib/rules/function-url-quotes/README.md): Require or disallow quotes for urls.
+- [`function-whitespace-after`](../../../lib/rules/function-whitespace-after/README.md): Require or disallow whitespace after functions (Autofixable).
+
+### Number
+
+- [`number-leading-zero`](../../../lib/rules/number-leading-zero/README.md): Require or disallow a leading zero for fractional numbers less than 1 (Autofixable).
+- [`number-no-trailing-zeros`](../../../lib/rules/number-no-trailing-zeros/README.md): Disallow trailing zeros in numbers (Autofixable).
+
+### String
+
+- [`string-quotes`](../../../lib/rules/string-quotes/README.md): Specify single or double quotes around strings (Autofixable).
+
+### Unit
+
+- [`unit-case`](../../../lib/rules/unit-case/README.md): Specify lowercase or uppercase for units (Autofixable).
+
+### Value
+
+- [`value-keyword-case`](../../../lib/rules/value-keyword-case/README.md): Specify lowercase or uppercase for keywords values (Autofixable).
+
+### 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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`value-list-max-empty-lines`](../../../lib/rules/value-list-max-empty-lines/README.md): Limit the number of adjacent empty lines within value lists (Autofixable).
+
+### 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 (Autofixable).
+
+### Property
+
+- [`property-case`](../../../lib/rules/property-case/README.md): Specify lowercase or uppercase for properties (Autofixable).
+
+### 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 (Autofixable).
+- [`declaration-bang-space-before`](../../../lib/rules/declaration-bang-space-before/README.md): Require a single space or disallow whitespace before the bang of declarations (Autofixable).
+- [`declaration-colon-newline-after`](../../../lib/rules/declaration-colon-newline-after/README.md): Require a newline or disallow whitespace after the colon of declarations (Autofixable).
+- [`declaration-colon-space-after`](../../../lib/rules/declaration-colon-space-after/README.md): Require a single space or disallow whitespace after the colon of declarations (Autofixable).
+- [`declaration-colon-space-before`](../../../lib/rules/declaration-colon-space-before/README.md): Require a single space or disallow whitespace before the colon of declarations (Autofixable).
+- [`declaration-empty-line-before`](../../../lib/rules/declaration-empty-line-before/README.md): Require or disallow an empty line before declarations (Autofixable).
+
+### Declaration block
+
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`declaration-block-trailing-semicolon`](../../../lib/rules/declaration-block-trailing-semicolon/README.md): Require or disallow a trailing semicolon within declaration blocks (Autofixable).
+
+### 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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`block-opening-brace-newline-after`](../../../lib/rules/block-opening-brace-newline-after/README.md): Require a newline after the opening brace of blocks (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+
+### 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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`selector-attribute-quotes`](../../../lib/rules/selector-attribute-quotes/README.md): Require or disallow quotes for attribute values.
+- [`selector-combinator-space-after`](../../../lib/rules/selector-combinator-space-after/README.md): Require a single space or disallow whitespace after the combinators of selectors (Autofixable).
+- [`selector-combinator-space-before`](../../../lib/rules/selector-combinator-space-before/README.md): Require a single space or disallow whitespace before the combinators of selectors (Autofixable).
+- [`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 (Autofixable).
+- [`selector-pseudo-class-case`](../../../lib/rules/selector-pseudo-class-case/README.md): Specify lowercase or uppercase for pseudo-class selectors (Autofixable).
+- [`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 (Autofixable).
+- [`selector-pseudo-element-case`](../../../lib/rules/selector-pseudo-element-case/README.md): Specify lowercase or uppercase for pseudo-element selectors (Autofixable).
+- [`selector-type-case`](../../../lib/rules/selector-type-case/README.md): Specify lowercase or uppercase for type selectors (Autofixable).
+
+### 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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+
+### Rule
+
+- [`rule-empty-line-before`](../../../lib/rules/rule-empty-line-before/README.md): Require or disallow an empty line before rules (Autofixable).
+
+### 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 (Autofixable).
+- [`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 (Autofixable).
+- [`media-feature-name-case`](../../../lib/rules/media-feature-name-case/README.md): Specify lowercase or uppercase for media feature names (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+
+### 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 (Autofixable).
+- [`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 (Autofixable).
+- [`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 (Autofixable).
+
+### At-rule
+
+- [`at-rule-empty-line-before`](../../../lib/rules/at-rule-empty-line-before/README.md): Require or disallow an empty line before at-rules (Autofixable).
+- [`at-rule-name-case`](../../../lib/rules/at-rule-name-case/README.md): Specify lowercase or uppercase for at-rules names (Autofixable).
+- [`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 (Autofixable).
+- [`at-rule-semicolon-newline-after`](../../../lib/rules/at-rule-semicolon-newline-after/README.md): Require a newline after the semicolon of at-rules (Autofixable).
+- [`at-rule-semicolon-space-before`](../../../lib/rules/at-rule-semicolon-space-before/README.md): Require a single space or disallow whitespace before the semicolons of at-rules.
+
+### Comment
+
+- [`comment-empty-line-before`](../../../lib/rules/comment-empty-line-before/README.md): Require or disallow an empty line before comments (Autofixable).
+- [`comment-whitespace-inside`](../../../lib/rules/comment-whitespace-inside/README.md): Require or disallow whitespace on the inside of comment markers (Autofixable).
+
+### General / Sheet
+
+- [`indentation`](../../../lib/rules/indentation/README.md): Specify indentation (Autofixable).
+- [`linebreaks`](../../../lib/rules/linebreaks/README.md): Specify unix or windows linebreaks (Autofixable).
+- [`max-empty-lines`](../../../lib/rules/max-empty-lines/README.md): Limit the number of adjacent empty lines (Autofixable).
+- [`max-line-length`](../../../lib/rules/max-line-length/README.md): Limit the length of a line.
+- [`no-eol-whitespace`](../../../lib/rules/no-eol-whitespace/README.md): Disallow end-of-line whitespace (Autofixable).
+- [`no-missing-end-of-source-newline`](../../../lib/rules/no-missing-end-of-source-newline/README.md): Disallow missing end-of-source newlines (Autofixable).
+- [`no-empty-first-line`](../../../lib/rules/no-empty-first-line/README.md): Disallow empty first lines (Autofixable).
+- [`unicode-bom`](../../../lib/rules/unicode-bom/README.md): Require or disallow Unicode BOM.
+- [`no-irregular-whitespace`](../../../lib/rules/no-irregular-whitespace/README.md): Disallow irregular whitespace.

node_modules/stylelint/docs/user-guide/rules/regex.md

@@ -0,0 +1,29 @@
+# Using regex in rules
+
+The following classes of rules support regex:
+
+- `*-allowed-list`
+- `*-disallowed-list`
+- `*-pattern`
+
+As does the `ignore*` secondary options.
+
+## Enforce a case
+
+You can use the regex that corresponds to your chosen case convention:
+
+<!-- prettier-ignore -->
+- 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]+$`
+
+For example, 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.
+
+## Enforce a prefix
+
+You can ensure a prefix by using a positive lookbehind regex.
+
+For example, to ensure all custom properties begin with `my-` use `"custom-property-pattern": "(?<=my-)"`.

node_modules/stylelint/docs/user-guide/usage/cli.md

@@ -0,0 +1,195 @@
+# Command Line Interface (CLI)
+
+You can use stylelint on the command line. For example:
+
+```shell
+npx stylelint "**/*.css"
+```
+
+Use `npx stylelint --help` to print the CLI documentation.
+
+## Options
+
+In addition to the [standard options](options.md), the CLI accepts:
+
+### `--allow-empty-input, --aei`
+
+The process exits without throwing an error when glob pattern matches no files.
+
+### `--cache-location`
+
+Path to a file or directory for the cache location. More info about this option in [standard options](options.md#cacheLocation).
+
+### `--cache`
+
+Store the results of processed files so that stylelint only operates on the changed ones. By default, the cache is stored in `./.stylelintcache` in `process.cwd()`. More info about this option in [standard options](options.md#cache).
+
+### `--color, --no-color`
+
+Force enabling/disabling of color.
+
+### `--config-basedir`
+
+Absolute path to the directory that relative paths defining "extends" and "plugins" are _relative to_. Only necessary if these values are relative paths. More info about this option in [standard options](options.md#configBasedir).
+
+### `--config`
+
+Path to a JSON, YAML, or JS file that contains your [configuration object](../configure.md). More info about this option in [standard options](options.md#configFile).
+
+### `--custom-syntax`
+
+Specify a custom syntax to use on your code. Use this option if you want to force a specific syntax that's not already built into stylelint. More info about this option in [standard options](options.md#customSyntax).
+
+### `--disable-default-ignores, --di`
+
+Disable the default ignores. stylelint will not automatically ignore the contents of `node_modules`. More info about this option in [standard options](options.md#disableDefaultIgnores).
+
+### `--fix`
+
+Automatically fix, where possible, violations reported by rules. More info about this option in [standard options](options.md#fix).
+
+### `--formatter, -f` | `--custom-formatter`
+
+Specify the formatter to format your results. More info about this option in [standard options](options.md#formatter).
+
+### `--ignore-disables, --id`
+
+Ignore `styleline-disable` (e.g. `/* stylelint-disable block-no-empty */`) comments. More info about this option in [standard options](options.md#ignoreDisables).
+
+### `--ignore-path, -i`
+
+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()`. More info about this option in [standard options](options.md#ignorePath).
+
+### `--ignore-pattern, --ip`
+
+Pattern of files to ignore (in addition to those in `.stylelintignore`).
+
+### `--max-warnings, --mw`
+
+Set a limit to the number of warnings accepted. More info about this option in [standard options](options.md#maxWarnings).
+
+### `--output-file, -o`
+
+Path of file to write a report. stylelint outputs the report to the specified `filename` in addition to the standard output.
+
+### `--print-config`
+
+Print the configuration for the given path. stylelint outputs the configuration used for the file passed.
+
+### `--quiet, -q`
+
+Only register violations for rules with an "error"-level severity (ignore "warning"-level).
+
+### `--report-descriptionless-disables, --rdd`
+
+Produce a report of the `stylelint-disable` comments without a description. More info about this option in [standard options](options.md#reportDescriptionlessDisables).
+
+### `--report-invalid-scope-disables, --risd`
+
+Produce a report of the `stylelint-disable` comments that used for rules that don't exist within the configuration object. More info about this option in [standard options](options.md#reportInvalidScopeDisables).
+
+### `--report-needless-disables, --rd`
+
+Produce a report to clean up your codebase, keeping only the `stylelint-disable` comments that serve a purpose. More info about this option in [standard options](options.md#reportNeedlessDisables).
+
+### `--stdin-filename`
+
+A filename to assign the input. More info about this option in [standard options](options.md#codeFilename).
+
+### `--stdin`
+
+Accept stdin input even if it is empty.
+
+### `--syntax, -s`
+
+Specify a syntax. More info about this option in [standard options](options.md#syntax).
+
+### `--version, -v`
+
+Show the currently installed version of stylelint.
+
+## Usage examples
+
+The CLI expects input as either a [file glob](https://github.com/sindresorhus/globby) or `process.stdin`. It outputs formatted results into `process.stdout`.
+
+_Be sure to include quotation marks around file globs._
+
+### Example A - recursive
+
+Recursively linting all `.css` files in the `foo` directory:
+
+```shell
+stylelint "foo/**/*.css"
+```
+
+### Example B - multiple file extensions
+
+Linting all `.css`, `.scss`, and `.sass` files:
+
+```shell
+stylelint "**/*.{css,scss,sass}"
+```
+
+### Example C - stdin
+
+Linting `stdin`:
+
+```shell
+echo "a { color: pink; }" | stylelint
+```
+
+### Example D - negation
+
+Linting all `.css` files except those within `docker` subfolders, using negation in the input glob:
+
+```shell
+stylelint "**/*.css" "!**/docker/**"
+```
+
+### Example E - caching
+
+Caching processed `.scss` files `foo` directory:
+
+```shell
+stylelint "foo/**/*.scss" --cache --cache-location "/Users/user/.stylelintcache/"
+```
+
+### Example F - writing a report
+
+Linting all `.css` files in the `foo` directory, then writing the output to `myTestReport.txt`:
+
+```shell
+stylelint "foo/*.css" --output-file myTestReport.txt
+```
+
+### Example G - specifying a config
+
+Using `bar/mySpecialConfig.json` as config to lint all `.css` files in the `foo` directory and any of its subdirectories:
+
+```shell
+stylelint "foo/**/*.css" --config bar/mySpecialConfig.json
+```
+
+### Example H - using a custom syntax
+
+Recursively linting all `.css` files in the `foo` directory using a custom syntax:
+
+```shell
+stylelint "foo/**/*.css" --customSyntax path/to/my-custom-syntax.js
+```
+
+### Example I - print on success
+
+Ensure output on successful runs:
+
+```shell
+stylelint -f verbose "foo/**/*.css"
+```
+
+## Exit codes
+
+The CLI can exit the process with the following exit codes:
+
+- `1` - something unknown went wrong
+- `2` - there was at least one rule violation or CLI flag error
+- `78` - there was some problem with the configuration file

node_modules/stylelint/docs/user-guide/usage/node-api.md

@@ -0,0 +1,169 @@
+# Node.js API
+
+The stylelint module includes a `lint()` function that provides the Node.js API.
+
+```js
+stylelint.lint(options).then(function (resultObject) {
+  /* .. */
+});
+```
+
+## Options
+
+In addition to the [standard options](options.md), the Node API accepts:
+
+### `config`
+
+A [configuration object](../configure.md).
+
+stylelint does not bother looking for a `.stylelintrc` file if you use this option.
+
+### `configOverrides`
+
+A partial stylelint configuration object whose properties override the existing config object, whether stylelint loads the config via the `config` option or a `.stylelintrc` file.
+
+### `code`
+
+A string to lint.
+
+### `files`
+
+A file glob, or array of [file globs](https://github.com/sindresorhus/globby).
+
+Relative globs are considered relative to `globbyOptions.cwd`.
+
+Though both `files` and `code` are "optional", you _must_ have one and _cannot_ have both.
+
+### `globbyOptions`
+
+The options that are passed with `files`.
+
+For example, you can set a specific `cwd` manually. Relative globs in `files` are considered relative to this path. And by default, `cwd` will be set by `process.cwd()`.
+
+For more detail usage, see [Globby Guide](https://github.com/sindresorhus/globby#options).
+
+## 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 violation.
+
+### `output`
+
+A string displaying the formatted violations (using the default formatter or whichever you passed).
+
+### `postcssResults`
+
+An array containing all the accumulated [PostCSS LazyResults](https://api.postcss.org/LazyResult.html).
+
+### `results`
+
+An array containing all the stylelint result objects (the objects that formatters consume).
+
+### `maxWarningsExceeded`
+
+An object containing the maximum number of warnings and the amount found, e.g. `{ maxWarnings: 0, foundWarnings: 12 }`.
+
+## 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
+
+### Example A
+
+As `config` contains no relative paths for `extends` or `plugins`, you do not have to use `configBasedir`:
+
+```js
+stylelint
+  .lint({
+    config: { rules: "color-no-invalid-hex" },
+    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);
+  });
+```
+
+### Example B
+
+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 () {
+    /* .. */
+  });
+```
+
+### Example C
+
+Using a string instead of a file glob, and the verbose formatter instead of the default JSON:
+
+```js
+stylelint
+  .lint({
+    code: "a { color: pink; }",
+    config: myConfig,
+    formatter: "verbose"
+  })
+  .then(function () {
+    /* .. */
+  });
+```
+
+### Example D
+
+Using your own custom formatter function and parse `.scss` source files:
+
+```js
+stylelint
+  .lint({
+    config: myConfig,
+    files: "all/my/stylesheets/*.scss",
+    formatter: function (stylelintResults) {
+      /* .. */
+    }
+  })
+  .then(function () {
+    /* .. */
+  });
+```
+
+### Example E
+
+Using a custom syntax:
+
+```js
+stylelint
+  .lint({
+    config: myConfig,
+    files: "all/my/stylesheets/*.css",
+    customSyntax: {
+      parse: (css, opts) => {
+        /* .. */
+      },
+      stringify: (root, builder) => {
+        /* .. */
+      }
+    }
+  })
+  .then(function () {
+    /* .. */
+  });
+```
+
+Note that the customSyntax option also accepts a string. [Refer to the options documentation for details](./options.md).

node_modules/stylelint/docs/user-guide/usage/options.md

@@ -0,0 +1,208 @@
+# Options
+
+Options shared by the:
+
+- [CLI](cli.md)
+- [Node.js API](node-api.md)
+- [PostCSS plugin](postcss-plugin.md)
+
+## `configFile`
+
+CLI flag: `--config`
+
+Path to a JSON, YAML, or JS file that contains your [configuration object](../configure.md).
+
+Use this option if you don't want stylelint to search for a configuration file.
+
+The path should be either absolute or relative to the directory that your process is running from (`process.cwd()`).
+
+## `configBasedir`
+
+CLI flag: `--config-basedir`
+
+Absolute path to the directory that relative paths defining "extends" and "plugins" are _relative to_. Only necessary if these values are relative paths.
+
+## `fix`
+
+CLI flag: `--fix`
+
+Automatically fix, where possible, violations reported by rules.
+
+For CSS with standard syntax, stylelint uses [postcss-safe-parser](https://github.com/postcss/postcss-safe-parser) to fix syntax errors.
+
+If a source contains a:
+
+- scoped disable comment, e.g. `/* stylelint-disable indentation */`, any violations reported by the scoped rules will not be automatically fixed anywhere in the source
+- unscoped disable comment, i.e. `/* stylelint-disable */`, the entirety of source will not be automatically fixed
+
+This limitation in being tracked in [issue #2643](https://github.com/stylelint/stylelint/issues/2643).
+
+## `formatter`
+
+CLI flags: `--formatter, -f` | `--custom-formatter`
+
+Specify the formatter to format your results.
+
+Options are:
+
+- `compact`
+- `json` (default for Node API)
+- `string` (default for CLI)
+- `tap`
+- `unix`
+- `verbose`
+
+The `formatter` Node.js API option can also accept a function, whereas the `--custom-formatter` CLI flag accepts a path to a JS file exporting one. The function in both cases must fit the signature described in the [Developer Guide](../../developer-guide/formatters.md).
+
+## `cache`
+
+CLI flag: `--cache`
+
+Store the results of processed files so that stylelint only operates on the changed ones. By default, the cache is stored in `./.stylelintcache` in `process.cwd()`.
+
+Enabling this option can dramatically improve stylelint's speed because only changed files are linted.
+
+_If you run stylelint with `cache` and then run stylelint without `cache`, stylelint deletes the `.stylelintcache` because we have to assume that that second command invalidated `.stylelintcache`._
+
+## `cacheLocation`
+
+CLI flag: `--cache-location`
+
+Path to a file or directory for the cache location.
+
+If a directory is specified, stylelint creates a cache file inside the specified folder. The name of the file is based on the hash of `process.cwd()` (e.g. `.cache_hashOfCWD`) so that stylelint can reuse a single location for a variety of caches from different projects.
+
+_If the directory of `cacheLocation` does not exist, make sure you add a trailing `/` on \*nix systems or `\` on Windows. Otherwise, stylelint assumes the path to be a file._
+
+## `maxWarnings`
+
+CLI flags: `--max-warnings, --mw`
+
+Set a limit to the number of warnings accepted.
+
+It is useful when setting [`defaultSeverity`](../configure.md#defaultseverity) to `"warning"` and expecting the process to fail on warnings (e.g. CI build).
+
+If the number of warnings exceeds this value, the:
+
+- CLI process exits with code `2`
+- Node.js API adds a [`maxWarningsExceeded`](node-api.md#maxwarningsexceeded) property to the returned data
+
+## `syntax`
+
+CLI flags: `--syntax, -s`
+
+Specify a syntax. Options:
+
+- `css`
+- `css-in-js`
+- `html`
+- `less`
+- `markdown`
+- `sass`
+- `scss`
+- `sugarss`
+
+If you do not specify a syntax, stylelint will automatically infer the syntaxes.
+
+Only use this option if you want to force a specific syntax.
+
+## `customSyntax`
+
+CLI flag: `--custom-syntax`
+
+Specify a custom syntax to use on your code. Use this option if you want to force a specific syntax that's not already built into stylelint.
+
+This option should be a string that resolves to a JS module that exports a [PostCSS-compatible syntax](https://github.com/postcss/postcss#syntaxes). The string can be a module name (like `my-module`) or a path to a JS file (like `path/to/my-module.js`).
+
+Using the Node.js API, the `customSyntax` option can also accept a [Syntax object](https://github.com/postcss/postcss/blob/abfaa7122a0f480bc5be0905df3c24a6a51a82d9/lib/postcss.d.ts#L223-L232). Stylelint treats the `parse` property as a required value.
+
+Note that stylelint can provide no guarantee that core rules work with syntaxes other than the defaults listed for the `syntax` option above.
+
+## `disableDefaultIgnores`
+
+CLI flags: `--disable-default-ignores, --di`
+
+Disable the default ignores. stylelint will not automatically ignore the contents of `node_modules`.
+
+## `ignorePath`
+
+CLI flags: `--ignore-path, -i`
+
+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()`.
+
+## `ignoreDisables`
+
+CLI flags: `--ignore-disables, --id`
+
+Ignore `styleline-disable` (e.g. `/* stylelint-disable block-no-empty */`) comments.
+
+You can use this option to see what your linting results would be like without those exceptions.
+
+## `reportNeedlessDisables`
+
+CLI flags: `--report-needless-disables, --rd`
+
+Produce a report to clean up your codebase, keeping only the `stylelint-disable` comments that serve a purpose.
+
+If needless disables are found, the:
+
+- CLI process exits with code `2`
+- Node.js API adds errors to the returned data
+
+## `reportInvalidScopeDisables`
+
+CLI flags: `--report-invalid-scope-disables, --risd`
+
+Produce a report of the `stylelint-disable` comments that used for rules that don't exist within the configuration object.
+
+If invalid scope disables are found, the:
+
+- CLI process exits with code `2`
+- Node.js API adds errors to the returned data
+
+## `reportDescriptionlessDisables`
+
+CLI flags: `--report-descriptionless-disables, --rdd`
+
+Produce a report of the `stylelint-disable` comments without a description.
+
+For example, when the configuration `{ block-no-empty: true }` is given, the following patterns are reported:
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable */
+a {}
+```
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable-next-line block-no-empty */
+a {}
+```
+
+But, the following patterns (`stylelint-disable -- <description>`) are _not_ reported:
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable -- This violation is ignorable. */
+a {}
+```
+
+<!-- prettier-ignore -->
+```css
+/* stylelint-disable-next-line block-no-empty -- This violation is ignorable. */
+a {}
+```
+
+If descriptionless disables are found, the:
+
+- CLI process exits with code `2`
+- Node.js API adds errors to the returned data
+
+## `codeFilename`
+
+CLI flag: `--stdin-filename`
+
+A filename to assign the input.
+
+If using `code` or `stdin` to pass a source string directly, you can use `codeFilename` to associate that code with a particular filename.

node_modules/stylelint/docs/user-guide/usage/postcss-plugin.md

@@ -0,0 +1,84 @@
+# 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](https://github.com/postcss/postcss#runners) or with the PostCSS JS API directly.
+
+_However, if a dedicated stylelint task runner plugin [is available](../integrations/task-runner.md) (e.g. [gulp-stylelint](https://github.com/olegskl/gulp-stylelint)) we recommend you use that rather than this plugin, as they provide better reporting._
+
+## Options
+
+The PostCSS plugin uses the [standard options](options.md), _except the `syntax` and `customSyntax` options_. 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.
+
+## 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 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/shellscape/postcss-less).
+
+```js
+const fs = require("fs");
+const less = require("postcss-less");
+const postcss = require("postcss");
+
+// Code to be processed
+const code = fs.readFileSync("input.less", "utf8");
+
+postcss([
+  require("stylelint")({
+    /* your options */
+  }),
+  require("postcss-reporter")({ clearReportedMessages: true })
+])
+  .process(code, {
+    from: "input.less",
+    syntax: less
+  })
+  .then(() => {})
+  .catch((err) => console.error(err.stack));
+```
+
+The same pattern can be used to lint Less, 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
+const fs = require("fs");
+const postcss = require("postcss");
+const stylelint = require("stylelint");
+
+// CSS to be processed
+const css = fs.readFileSync("lib/app.css", "utf8");
+
+postcss([
+  require("postcss-import")({
+    plugins: [
+      require("stylelint")({
+        /* your options */
+      })
+    ]
+  }),
+  require("postcss-preset-env"),
+  require("postcss-reporter")({ clearReportedMessages: true })
+])
+  .process(css, {
+    from: "lib/app.css",
+    to: "app.css"
+  })
+  .then((result) => {
+    fs.writeFileSync("app.css", result.css);
+
+    if (result.map) {
+      fs.writeFileSync("app.css.map", result.map);
+    }
+  })
+  .catch((err) => console.error(err.stack));
+```