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.