create-docusaurus 0.0.0-4378 → 0.0.0-4379

package/templates/facebook/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.

package/templates/facebook/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.

package/templates/facebook/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.

package/templates/facebook/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.

package/templates/facebook/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.

package/templates/facebook/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\]"