docs: standardized rule docs heading and option-less Options (#4367)

Author: Josh Goldberg

packages/eslint-plugin/docs/rules/TEMPLATE.md

@@ -0,0 +1,57 @@
+# `your-rule-name`
+
+Your rule description here.
+
+## Rule Details
+
+To fill out: tell us more about this rule.
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+// To fill out: incorrect code
+```
+
+### ✅ Correct
+
+```ts
+// To fill out: correct code
+```
+
+## Options
+
+```jsonc
+// .eslintrc.json
+{
+  "rules": {
+    "@typescript-eslint/your-rule-name": "error"
+  }
+}
+```
+
+If not configurable: This rule is not configurable.
+
+If configurable...
+
+```ts
+type Options = {
+  someOption?: boolean;
+};
+
+const defaultOptions: Options = {
+  someOption: false,
+};
+```
+
+## When Not To Use It
+
+To fill out: why wouldn't you want to use this rule?
+For example if this rule requires a feature released in a certain TS version.
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [ ] 🔧 Fixable
+- [ ] 💭 Requires type information

packages/eslint-plugin/docs/rules/adjacent-overload-signatures.md

@@ -1,4 +1,6 @@
-# Require that member overloads be consecutive (`adjacent-overload-signatures`)
+# `adjacent-overload-signatures`
+
+Require that member overloads be consecutive.
 
 Grouping overloaded members together can improve readability of the code.
 
@@ -82,6 +84,19 @@ export function foo(n: number): void;
 export function foo(sn: string | number): void;
 ```
 
+## Options
+
+```jsonc
+// .eslintrc.json
+{
+  "rules": {
+    "@typescript-eslint/adjacent-overload-signatures": "error"
+  }
+}
+```
+
+This rule is not configurable.
+
 ## When Not To Use It
 
 If you don't care about the general structure of the code, then you will not need this rule.

packages/eslint-plugin/docs/rules/array-type.md

@@ -1,4 +1,6 @@
-# Requires using either `T[]` or `Array<T>` for arrays (`array-type`)
+# `array-type`
+
+Requires using either `T[]` or `Array<T>` for arrays.
 
 Using the same style for array definitions across your codebase makes it easier for your developers to read and understand the types.
 

packages/eslint-plugin/docs/rules/await-thenable.md

@@ -1,4 +1,6 @@
-# Disallows awaiting a value that is not a Thenable (`await-thenable`)
+# `await-thenable`
+
+Disallows awaiting a value that is not a Thenable.
 
 This rule disallows awaiting a value that is not a "Thenable" (an object which has `then` method, such as a Promise).
 While it is valid JavaScript to await a non-`Promise`-like value (it will resolve immediately), this pattern is often a programmer error, such as forgetting to add parenthesis to call a function that returns a Promise.
@@ -27,6 +29,19 @@ const createValue = async () => 'value';
 await createValue();
 ```
 
+## Options
+
+```jsonc
+// .eslintrc.json
+{
+  "rules": {
+    "@typescript-eslint/await-thenable": "error"
+  }
+}
+```
+
+This rule is not configurable.
+
 ## When Not To Use It
 
 If you want to allow code to `await` non-Promise values.

packages/eslint-plugin/docs/rules/ban-ts-comment.md

@@ -1,4 +1,6 @@
-# Bans `@ts-<directive>` comments from being used or requires descriptions after directive (`ban-ts-comment`)
+# `ban-ts-comment`
+
+Bans `@ts-<directive>` comments from being used or requires descriptions after directive.
 
 TypeScript provides several directive comments that can be used to alter how it processes files.
 Using these to suppress TypeScript Compiler Errors reduces the effectiveness of TypeScript overall.

packages/eslint-plugin/docs/rules/ban-tslint-comment.md

@@ -1,4 +1,6 @@
-# Bans `// tslint:<rule-flag>` comments from being used (`ban-tslint-comment`)
+# `ban-tslint-comment`
+
+Bans `// tslint:<rule-flag>` comments from being used.
 
 Useful when migrating from TSLint to ESLint. Once TSLint has been removed, this rule helps locate TSLint annotations (e.g. `// tslint:disable`).
 

packages/eslint-plugin/docs/rules/ban-types.md

@@ -1,4 +1,6 @@
-# Bans specific types from being used (`ban-types`)
+# `ban-types`
+
+Bans specific types from being used.
 
 Some builtin types have aliases, some types are considered dangerous or harmful.
 It's often a good idea to ban certain types to help with consistency and safety.

packages/eslint-plugin/docs/rules/brace-style.md

@@ -1,4 +1,6 @@
-# Enforce consistent brace style for blocks (`brace-style`)
+# `brace-style`
+
+Enforce consistent brace style for blocks.
 
 ## Rule Details
 

packages/eslint-plugin/docs/rules/class-literal-property-style.md

@@ -1,4 +1,6 @@
-# Ensures that literals on classes are exposed in a consistent style (`class-literal-property-style`)
+# `class-literal-property-style`
+
+Ensures that literals on classes are exposed in a consistent style.
 
 When writing TypeScript applications, it's typically safe to store literal values on classes using fields with the `readonly` modifier to prevent them from being reassigned.
 When writing TypeScript libraries that could be used by JavaScript users however, it's typically safer to expose these literals using `getter`s, since the `readonly` modifier is enforced at compile type.

packages/eslint-plugin/docs/rules/comma-dangle.md

@@ -1,4 +1,6 @@
-# Require or disallow trailing comma (`comma-dangle`)
+# `comma-dangle`
+
+Require or disallow trailing comma.
 
 ## Rule Details