Docs: Add markdownlint and convert trailing spaces for newlines backslashes (#494)

Author: bmish

.devcontainer/devcontainer.json

@@ -7,7 +7,7 @@
 		// Update 'VARIANT' to pick a Node version: 16, 14, 12.
 		// Append -bullseye or -buster to pin to an OS version.
 		// Use -bullseye variants on local on arm64/Apple Silicon.
-		"args": { 
+		"args": {
 			"VARIANT": "14"
 		}
 	},
@@ -29,4 +29,4 @@
 
 	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
 	"remoteUser": "node"
-}
+}

.markdownlint.json

@@ -0,0 +1,5 @@
+{
+  "line-length": false,
+  "no-inline-html": false,
+  "single-title": false
+}

.markdownlintignore

@@ -0,0 +1,3 @@
+CHANGELOG.md
+LICENSE
+node_modules

CONTRIBUTING.md

@@ -2,26 +2,22 @@
 
 👍🎉 First off, thanks for taking the time to contribute! 🎉👍
 
-
 ## Reporting bugs
 
 To report a bug, [open an issue][new-issue].
 
 If you are unsure whether something is a bug or not, please [open an issue][new-issue]. Insufficient documentation is also a bug.
 
-
 ## Suggesting new features
 
 New features can be a new rule, anew option for an existing rule, or new functionality for existing rules.
 
 To suggest a new feature, [open an issue][new-issue].
 
-
 ## Making pull requests
 
 (If this is your first pull request on GitHub, checkout [this guide](https://github.com/firstcontributions/first-contributions).)
 
-
 ### Getting started
 
 - This is a TypeScript project. You need to have a recentish version of [Node.js](https://nodejs.org/) and npm installed.
@@ -30,12 +26,11 @@ To suggest a new feature, [open an issue][new-issue].
 
 We use [ESLint](https://eslint.org/) and [Prettier](https://prettier.io/) to lint and format our code base. They will be automatically installed as dependencies but you might need additional editor plugins for a good IDE experience. We recommend using [VSCode](https://code.visualstudio.com/) together with the [ESLint plugin](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) for a great editing experience.
 
-
 ### Creating a new rule
 
 The following steps will walk you through the process of creating a new rule.
 
-1.  Run `npm run new <rule-name>`:
+1. Run `npm run new <rule-name>`:
 
     This will automatically create 3 files:
 
@@ -45,33 +40,32 @@ The following steps will walk you through the process of creating a new rule.
 
     These 3 files contain all the information about your new rule. You only need to touch these 3 files to add your rule.
 
-1.  Add meta information:
+1. Add meta information:
 
     Fill in the rule's meta information in the `meta` object. This includes a short description, its category, type, and more.
 
     Note: Do not set `recommended: true`. This will add your rule to the `regex/recommended` configuration. We view additions to the `regex/recommended` configuration as breaking changes. If you want your rule to be included in the `regex/recommended` configuration in the next major release, leave the generated TODO comment as is.
 
     Once you added a short description and the category, run `npm run update`. This will update a few generated files to include your rule in the website and more.
 
-1.  Implement your rule:
+1. Implement your rule:
 
     The `createVisitor` function will be where you implement your rule. The `regexpContext` object contains information and methods that you will need for static analysis, reporting, and fixing. Use `messageId`s for report and suggestion messages.
 
     The [`no-empty-capturing-group`](./lib/rules/no-empty-capturing-group.ts) and [`no-octal`](./lib/rules/no-octal.ts) rules are good examples to see how we usually implement rules.
 
-1.  Test your rule:
+1. Test your rule:
 
     Add test for every feature and option of your rule. (We use [ESLint's `RuleTester`](https://eslint.org/docs/developer-guide/nodejs-api#ruletester) for testing rules.)
 
     Use `npm test` to run all tests.
 
-1.  Document your rule:
+1. Document your rule:
 
     The documentation should contain a description of the rule and the problem it detects/solves, examples, all features, all options, and any additional information relevant to the rule.
 
     You can view the documentation live in your browser by running `npm run docs:watch`. The live view will automatically update when you make changes to the documentation. However, you have to re-load the browser to see changes to the rule implementation.
 
-
 ### Updating documentation
 
 Almost all Markdown files of our website and the project `README.md` are partially or completely generated.
@@ -93,24 +87,23 @@ After you changed the documentation, run `npm run update` to update all generate
 
 You can view changes to the website locally by running `npm run docs:watch`.
 
-
 ### Testing
 
 Aside from `npm test`, there are also a few other ways to manually test new features, changes, and new rules.
 
-1.  `npm run docs:watch`:
+1. `npm run docs:watch`:
 
     The documentation page of each rule includes interactive examples. You can also use your local version of [the playground](https://ota-meshi.github.io/eslint-plugin-regexp/playground/) to for testing.
 
-1.  Test your rule and the whole plugin by installing it.
+1. Test your rule and the whole plugin by installing it.
 
     If there is a project/code base you want to test your rule/the entire plugin on, then installing this project will be the right solution.
 
     [Setup ESLint](https://eslint.org/docs/user-guide/getting-started) in the target project. Instead of installing the `eslint-plugin-regexp` from the npm registry, install your local `eslint-plugin-regexp` project using the relative path to the project.
 
     Example:
 
-    ```
+    ```plaintext
     projects/
     ├── target/
     |   └── package.json
@@ -124,7 +117,6 @@ Aside from `npm test`, there are also a few other ways to manually test new feat
 
     Note: If you make changes to the implementation of a rule, you'll have to run `npm run build` before these changes show up in the target project.
 
-
 <!-- Important links -->
 
 [new-issue]: https://github.com/ota-meshi/eslint-plugin-regexp/issues/new/choose

docs/rules/confusing-quantifier.md

@@ -44,7 +44,7 @@ Nothing.
 
 ## :heart: Compatibility
 
-This rule was taken from [eslint-plugin-clean-regex].  
+This rule was taken from [eslint-plugin-clean-regex].\
 This rule is compatible with [clean-regex/confusing-quantifier] rule.
 
 [eslint-plugin-clean-regex]: https://github.com/RunDevelopment/eslint-plugin-clean-regex

docs/rules/control-character-escape.md

@@ -18,6 +18,8 @@ This rule reports control characters that were not escaped using a control escap
 
 <eslint-code-block fix>
 
+<!-- markdownlint-disable no-hard-tabs -->
+
 ```js
 /* eslint regexp/control-character-escape: "error" */
 
@@ -33,6 +35,8 @@ var foo = /\u{a}/u;
 var foo = RegExp("\\u000a");
 ```
 
+<!-- markdownlint-enable no-hard-tabs -->
+
 </eslint-code-block>
 
 ## :wrench: Options

docs/rules/hexadecimal-escape.md

@@ -37,7 +37,7 @@ var foo = /\u{a}/u;
 ```json5
 {
   "regexp/hexadecimal-escape": [
-    "error", 
+    "error",
     "always", // or "never"
   ]
 }

docs/rules/index.md

@@ -4,9 +4,10 @@ sidebarDepth: 0
 
 # Available Rules
 
-The `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) automatically fixes problems reported by rules which have a wrench :wrench: below.  
+The `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) automatically fixes problems reported by rules which have a wrench :wrench: below.\
 The rules with the following star :star: are included in the `plugin:regexp/recommended` config.
 
+<!-- markdownlint-disable heading-increment -->
 <!-- This file is automatically generated in tools/update-docs-rules-index.js, do not change! -->
 
 ### Possible Errors

docs/rules/match-any.md

@@ -14,7 +14,7 @@ since: "v0.1.0"
 
 ## :book: Rule Details
 
-This rule enforces the regular expression notation to match any character.  
+This rule enforces the regular expression notation to match any character.\
 e.g. `[\s\S]`, `[^]`, `/./s` (dotAll) and more.
 
 <eslint-code-block fix>
@@ -45,7 +45,7 @@ var foo = /[\w\W]/;
 }
 ```
 
-- `"allows"` ... An array of notations that any characters that are allowed.  
+- `"allows"` ... An array of notations that any characters that are allowed.\
   `"[\\s\\S]"`, `"[\\S\\s]"`, `"[^]"` and `"dotAll"` can be set.
 
 ### `{ "allows": ["[^]"] }`

docs/rules/no-contradiction-with-assertion.md

@@ -45,7 +45,6 @@ This rule reports elements that contradict an assertion. All elements reported b
 
 This rule is quite similar to [regexp/no-useless-assertions]. While [regexp/no-useless-assertions] tries to find assertions that contradict the pattern, this rule tries to find parts of the pattern that contradict assertions.
 
-
 <eslint-code-block>
 
 ```js

docs/rules/no-empty-alternative.md

@@ -40,13 +40,12 @@ Nothing.
 
 ## :heart: Compatibility
 
-This rule was taken from [eslint-plugin-clean-regex].  
+This rule was taken from [eslint-plugin-clean-regex].\
 This rule is compatible with [clean-regex/no-empty-alternative] rule.
 
 [eslint-plugin-clean-regex]: https://github.com/RunDevelopment/eslint-plugin-clean-regex
 [clean-regex/no-empty-alternative]: https://github.com/RunDevelopment/eslint-plugin-clean-regex/blob/master/docs/rules/no-empty-alternative.md
 
-
 ## :rocket: Version
 
 This rule was introduced in eslint-plugin-regexp v0.8.0

docs/rules/no-empty-lookarounds-assertion.md

@@ -21,10 +21,10 @@ An empty lookaround is a lookaround for which at least one path in the lookaroun
 
 **Examples:**
 
--   `(?=)`: One of simplest empty lookarounds.
--   `(?=a*)`: It is possible for `a*` to not consume characters, therefore the lookahead is _empty_.
--   `(?=a|b*)`: Only one path has to not consume characters. Since it is possible for `b*` to not consume characters, the lookahead is _empty_.
--   `(?=a|$)`: This is **not** an empty lookaround. `$` does not _consume_ characters but it does _assert_ characters. Similarly, all other standard assertions (`\b`, `\B`, `^`) are also not empty.
+- `(?=)`: One of simplest empty lookarounds.
+- `(?=a*)`: It is possible for `a*` to not consume characters, therefore the lookahead is _empty_.
+- `(?=a|b*)`: Only one path has to not consume characters. Since it is possible for `b*` to not consume characters, the lookahead is _empty_.
+- `(?=a|$)`: This is **not** an empty lookaround. `$` does not _consume_ characters but it does _assert_ characters. Similarly, all other standard assertions (`\b`, `\B`, `^`) are also not empty.
 
 ### Why are empty lookarounds a problem?
 

docs/rules/no-escape-backspace.md

@@ -13,7 +13,7 @@ since: "v0.1.0"
 
 ## :book: Rule Details
 
-This rule reports `[\b]`.  
+This rule reports `[\b]`.\
 The word boundaries (`\b`) and the escape backspace (`[\b]`) are indistinguishable at a glance. This rule does not allow backspace (`[\b]`). Use unicode escapes (`\u0008`) instead.
 
 <eslint-code-block>

docs/rules/no-invisible-character.md

@@ -18,6 +18,8 @@ This rule disallows using invisible characters other than SPACE (`U+0020`) witho
 
 <eslint-code-block fix>
 
+<!-- markdownlint-disable no-hard-tabs -->
+
 ```js
 /* eslint regexp/no-invisible-character: "error" */
 
@@ -35,6 +37,8 @@ var foo = //;
 var foo = /　/;
 ```
 
+<!-- markdownlint-enable no-hard-tabs -->
+
 </eslint-code-block>
 
 ## :wrench: Options

docs/rules/no-lazy-ends.md

@@ -110,7 +110,7 @@ var foo = /a(?:c|ab+?)?/.test(str)
 
 ## :heart: Compatibility
 
-This rule was taken from [eslint-plugin-clean-regex].  
+This rule was taken from [eslint-plugin-clean-regex].\
 This rule is compatible with [clean-regex/no-lazy-ends] rule.
 
 [eslint-plugin-clean-regex]: https://github.com/RunDevelopment/eslint-plugin-clean-regex

docs/rules/no-legacy-features.md

@@ -60,7 +60,7 @@ regexObj.compile('new foo', 'g');
       "rightContext", "$'",
       "$1", "$2", "$3", "$4", "$5", "$6", "$7", "$8", "$9"
     ],
-    "prototypeMethods": ["compile"] 
+    "prototypeMethods": ["compile"]
   }]
 }
 ```

docs/rules/no-missing-g-flag.md

@@ -48,7 +48,7 @@ var newText = text.replaceAll(/Dog/i, 'cat');
 }
 ```
 
-- `strictTypes` ... If `true`, strictly check the type of object to determine if the regex instance was used in `matchAll()` and `replaceAll()`. Default is `true`.  
+- `strictTypes` ... If `true`, strictly check the type of object to determine if the regex instance was used in `matchAll()` and `replaceAll()`. Default is `true`.\
   This option is always on when using TypeScript.
 
 ## :books: Further reading

docs/rules/no-obscure-range.md

@@ -41,7 +41,6 @@ var foo = /[😀-😄]/u;
 
 ## :wrench: Options
 
-
 ```json5
 {
   "regexp/no-obscure-range": ["error",

docs/rules/no-optional-assertion.md

@@ -46,7 +46,7 @@ Nothing.
 
 ## :heart: Compatibility
 
-This rule was taken from [eslint-plugin-clean-regex].  
+This rule was taken from [eslint-plugin-clean-regex].\
 This rule is compatible with [clean-regex/no-optional-assertion] rule.
 
 [eslint-plugin-clean-regex]: https://github.com/RunDevelopment/eslint-plugin-clean-regex

docs/rules/no-potentially-useless-backreference.md

@@ -47,7 +47,7 @@ Nothing.
 
 ## :heart: Compatibility
 
-This rule was taken from [eslint-plugin-clean-regex].  
+This rule was taken from [eslint-plugin-clean-regex].\
 This rule is compatible with [clean-regex/no-potentially-empty-backreference] rule.
 
 [eslint-plugin-clean-regex]: https://github.com/RunDevelopment/eslint-plugin-clean-regex

docs/rules/no-super-linear-backtracking.md

@@ -44,7 +44,6 @@ The rule only implements a very simplistic detection method and can only detect
 
 While the detection will improve in the future, this rule will never be able to perfectly detect all cases super-linear backtracking.
 
-
 ## :wrench: Options
 
 ```json

docs/rules/no-super-linear-move.md

@@ -149,7 +149,6 @@ This rule implements a simple detection method. It is unable to find certain cas
 
 This means that this rule might not be able to verify fixed regexes. This rule might be unable to detect that supposedly fixed regexes are actually still vulnerable.
 
-
 ## :wrench: Options
 
 ```json
@@ -179,7 +178,7 @@ This option determines whether this rule will ignore regexes with sticky (`y`) f
 
   All regexes will be analysed.
 
-### `ignorePartial: boolean`:
+### `ignorePartial: boolean`
 
 Some regexes are used as fragments to build more complex regexes. Example:
 
@@ -198,7 +197,6 @@ Even if a fragment had exploitable quantifiers, it might not cause super-linear
 
   The rule checks all regexes regardless of how they are used.
 
-
 ## :books: Further reading
 
 - [Regular expression Denial of Service - ReDoS][1]

docs/rules/no-useless-assertions.md

@@ -47,7 +47,7 @@ Nothing.
 
 ## :heart: Compatibility
 
-This rule was taken from [eslint-plugin-clean-regex].  
+This rule was taken from [eslint-plugin-clean-regex].\
 This rule is compatible with [clean-regex/no-unnecessary-assertions] rule.
 
 [eslint-plugin-clean-regex]: https://github.com/RunDevelopment/eslint-plugin-clean-regex

docs/rules/no-useless-escape.md

@@ -14,7 +14,7 @@ since: "v0.4.0"
 
 ## :book: Rule Details
 
-This rule reports unnecessary escape characters in RegExp.  
+This rule reports unnecessary escape characters in RegExp.\
 You may be able to find another mistake by finding unnecessary escapes.
 
 <eslint-code-block fix>

docs/rules/no-useless-flag.md

@@ -166,7 +166,7 @@ No other flags will be checked.
 ```
 
 - `ignore` ... An array of flags to ignore from the check.
-- `strictTypes` ... If `true`, strictly check the type of object to determine if the regex instance was used in `search()` and `split()`. Default is `true`. This option is only effective for verifying the `g` and `y` flags.  
+- `strictTypes` ... If `true`, strictly check the type of object to determine if the regex instance was used in `search()` and `split()`. Default is `true`. This option is only effective for verifying the `g` and `y` flags.\
   This option is always on when using TypeScript.
 
 ### `"ignore": ["s", "g"]`

docs/rules/optimal-lookaround-quantifier.md

@@ -63,7 +63,7 @@ Nothing.
 
 ## :heart: Compatibility
 
-This rule was taken from [eslint-plugin-clean-regex].  
+This rule was taken from [eslint-plugin-clean-regex].\
 This rule is compatible with [clean-regex/optimal-lookaround-quantifier] rule.
 
 [eslint-plugin-clean-regex]: https://github.com/RunDevelopment/eslint-plugin-clean-regex