docs: split rules documentation

docs/src/contribute/contribute-core-rule.md → docs/src/contribute/core-rules.md

@@ -11,20 +11,20 @@ The ESLint core rules are the rules included in the ESLint package.
 
 ## Rule Writing Documentation
 
-For full reference information on writing rules, refer to [Custom Rules](../extend/custom-rules). Both custom rules and core rules have the same structure and API. The primary difference between core and custom rules are:
+For full reference information on writing rules, refer to [Custom Rules](../extend/custom-rules). Both custom rules and core rules have the same API. The primary difference between core and custom rules are:
 
 1. Core rules are included in the `eslint` package.
-1. Core rules must adhere to the structure documented on this page.
+1. Core rules must adhere to the conventions documented on this page.
 
-## Core Rule Structure
+## File Structure
 
 Each core rule in ESLint has three files named with its identifier (for example, `no-extra-semi`).
 
 * in the `lib/rules` directory: a source file (for example, `no-extra-semi.js`)
 * in the `tests/lib/rules` directory: a test file (for example, `no-extra-semi.js`)
 * in the `docs/src/rules` directory: a Markdown documentation file (for example, `no-extra-semi.md`)
 
-**Important:** If you submit a **core** rule to the ESLint repository, you **must** follow some conventions explained below.
+**Important:** If you submit a core rule to the ESLint repository, you **must** follow some conventions explained below.
 
 Here is the basic format of the source file for a rule:
 
@@ -40,7 +40,7 @@ Here is the basic format of the source file for a rule:
 // Rule Definition
 //------------------------------------------------------------------------------
 
-/** @type {import('eslint').Rule.RuleModule} */
+/** @type {import('../shared/types').Rule} */
 module.exports = {
     meta: {
         type: "suggestion",
@@ -71,7 +71,7 @@ ESLint provides the [`RuleTester`](../integrate/nodejs-api#ruletester) utility t
 
 To keep the linting process efficient and unobtrusive, it is useful to verify the performance impact of new rules or modifications to existing rules.
 
-### Overall Performance
+To learn how to profile the performance of individual rules, refer to [Profile Rule Performance](../extend/custom-rules#profile-rule-performance) in the custom rules documentation.
 
 When developing in the ESLint core repository, the `npm run perf` command gives a high-level overview of ESLint running time with all core rules enabled.
 
@@ -101,41 +101,10 @@ Performance Run #5:  1457.455283ms
 Performance budget ok:  1443.736547ms (limit: 3409.090909090909ms)
 ```
 
-### Per-rule Performance
-
-ESLint has a built-in method to track the performance of individual rules. Setting the `TIMING` environment variable will trigger the display, upon linting completion, of the ten longest-running rules, along with their individual running time (rule creation + rule execution) and relative performance impact as a percentage of total rule processing time (rule creation + rule execution).
-
-```bash
-$ TIMING=1 eslint lib
-Rule                    | Time (ms) | Relative
-:-----------------------|----------:|--------:
-no-multi-spaces         |    52.472 |     6.1%
-camelcase               |    48.684 |     5.7%
-no-irregular-whitespace |    43.847 |     5.1%
-valid-jsdoc             |    40.346 |     4.7%
-handle-callback-err     |    39.153 |     4.6%
-space-infix-ops         |    35.444 |     4.1%
-no-undefined            |    25.693 |     3.0%
-no-shadow               |    22.759 |     2.7%
-no-empty-class          |    21.976 |     2.6%
-semi                    |    19.359 |     2.3%
-```
-
-To test one rule explicitly, combine the `--no-eslintrc`, and `--rule` options:
-
-```bash
-$ TIMING=1 eslint --no-eslintrc --rule "quotes: [2, 'double']" lib
-Rule   | Time (ms) | Relative
-:------|----------:|--------:
-quotes |    18.066 |   100.0%
-```
-
-To see a longer list of results (more than 10), set the environment variable to another value such as `TIMING=50` or `TIMING=all`.
-
 ## Rule Naming Conventions
 
-The rule naming conventions for ESLint are fairly simple:
+The rule naming conventions for ESLint are as follows:
 
-* If your rule is disallowing something, prefix it with `no-` such as `no-eval` for disallowing `eval()` and `no-debugger` for disallowing `debugger`.
-* If your rule is enforcing the inclusion of something, use a short name without a special prefix.
 * Use dashes between words.
+* If your rule only disallows something, prefix it with `no-` such as `no-eval` for disallowing `eval()` and `no-debugger` for disallowing `debugger`.
+* If your rule is enforcing the inclusion of something, use a short name without a special prefix.

docs/src/contribute/index.md

@@ -54,7 +54,7 @@ Have some extra time and want to contribute? This section talks about the proces
 
 We're always looking for contributions from the community. This section explains the requirements for pull requests and the process of contributing code.
 
-## [Contribute to Core Rules](contribute-core-rule)
+## [Contribute to Core Rules](core-rules)
 
 This section explains how to add to the core rules of ESLint.
 

docs/src/extend/custom-rules.md

@@ -675,7 +675,7 @@ ESLint provides the [`RuleTester`](../integrate/nodejs-api#ruletester) utility t
 
 ## Rule Naming Conventions
 
-While you can give a custom rule any name you'd like, the core rules have naming conventions that it could be clearer to apply to your custom rule. To learn more, refer to the [Core Rule Naming Conventions](../contribute/contribute-core-rule#rule-naming-conventions) documentation.
+While you can give a custom rule any name you'd like, the core rules have naming conventions that it could be clearer to apply to your custom rule. To learn more, refer to the [Core Rule Naming Conventions](../contribute/core-rulse#rule-naming-conventions) documentation.
 
 ## Runtime Rules
 
@@ -686,3 +686,34 @@ Runtime rules are written in the same format as all other rules. Create your rul
 1. Place all of your runtime rules in the same directory (e.g., `eslint_rules`).
 2. Create a [configuration file](../use/configure/) and specify your rule ID error level under the `rules` key. Your rule will not run unless it has a value of `"warn"` or `"error"` in the configuration file.
 3. Run the [command line interface](../use/command-line-interface) using the `--rulesdir` option to specify the location of your runtime rules.
+
+## Profile Rule Performance
+
+ESLint has a built-in method to track the performance of individual rules. Setting the `TIMING` environment variable will trigger the display, upon linting completion, of the ten longest-running rules, along with their individual running time (rule creation + rule execution) and relative performance impact as a percentage of total rule processing time (rule creation + rule execution).
+
+```bash
+$ TIMING=1 eslint lib
+Rule                    | Time (ms) | Relative
+:-----------------------|----------:|--------:
+no-multi-spaces         |    52.472 |     6.1%
+camelcase               |    48.684 |     5.7%
+no-irregular-whitespace |    43.847 |     5.1%
+valid-jsdoc             |    40.346 |     4.7%
+handle-callback-err     |    39.153 |     4.6%
+space-infix-ops         |    35.444 |     4.1%
+no-undefined            |    25.693 |     3.0%
+no-shadow               |    22.759 |     2.7%
+no-empty-class          |    21.976 |     2.6%
+semi                    |    19.359 |     2.3%
+```
+
+To test one rule explicitly, combine the `--no-eslintrc`, and `--rule` options:
+
+```bash
+$ TIMING=1 eslint --no-eslintrc --rule "quotes: [2, 'double']" lib
+Rule   | Time (ms) | Relative
+:------|----------:|--------:
+quotes |    18.066 |   100.0%
+```
+
+To see a longer list of results (more than 10), set the environment variable to another value such as `TIMING=50` or `TIMING=all`.