create-docusaurus 0.0.0-4483 → 0.0.0-4487

package/templates/facebook/node_modules/stylelint/docs/user-guide/get-started.md

@@ -1,55 +0,0 @@
-# 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

@@ -1,88 +0,0 @@
-# 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

@@ -1,12 +0,0 @@
-# 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

@@ -1,19 +0,0 @@
-# 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

@@ -1,10 +0,0 @@
-# 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

@@ -1,203 +0,0 @@
-# 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\]"