process and actually display something useful

lint_rules/adjacent_overload_signatures.md

@@ -3,7 +3,7 @@ Requires overload signatures to be adjacent to each other.
 Overloaded signatures which are not next to each other can lead to code which is
 hard to read and maintain.
 
-### Invalid:
+**Invalid:**
 
 (`bar` is declared in-between `foo` overloads)
 
@@ -41,7 +41,7 @@ export function bar(): void {}
 export function foo(sn: string | number): void {}
 ```
 
-### Valid:
+**Valid:**
 
 (`bar` is declared after `foo`)
 

lint_rules/ban_ts_comment.md

@@ -4,7 +4,7 @@ Typescript directives reduce the effectiveness of the compiler, something which
 should only be done in exceptional circumstances. The reason why should be
 documented in a comment alongside the directive.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // @ts-expect-error
@@ -21,7 +21,7 @@ let a: number = "I am a string";
 let a: number = "I am a string";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // @ts-expect-error: Temporary workaround (see ticket #422)

lint_rules/ban_types.md

@@ -17,7 +17,7 @@ safety with the function.
 Finally, `Object` and `{}` means "any non-nullish value" rather than "any object
 type". `object` is a good choice for a meaning of "any object type".
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let a: Boolean;
@@ -29,7 +29,7 @@ let f: Object;
 let g: {};
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let a: boolean;

lint_rules/ban_unknown_rule_code.md

@@ -12,7 +12,7 @@ const foo: any = 42;
 This rule checks for the validity of the specified rule names (i.e. whether
 `deno_lint` provides the rule or not).
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // typo
@@ -24,7 +24,7 @@ console.assert(x == 42);
 const b = "b";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // deno-lint-ignore eq-eq-eq

lint_rules/ban_untagged_ignore.md

@@ -3,14 +3,14 @@ Requires `deno-lint-ignore` to be annotated with one or more rule names.
 Ignoring all rules can mask unexpected or future problems. Therefore you need to
 explicitly specify which rule(s) are to be ignored.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // deno-lint-ignore
 export function duplicateArgumentsFn(a, b, a) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // deno-lint-ignore no-dupe-args

lint_rules/ban_untagged_todo.md

@@ -4,7 +4,7 @@ reference (`#issue`).
 TODOs without reference to a user or an issue become stale with no easy way to
 get more information.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // TODO Improve calc engine
@@ -21,7 +21,7 @@ export function calcValue(): number {}
 export function calcValue(): number {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // TODO(djones) Improve calc engine

lint_rules/ban_unused_ignore.md

@@ -9,7 +9,7 @@ likely to confuse future code readers, and to make matters worse, might hide
 future lint errors unintentionally. To prevent such situations, this rule
 detects unused, superfluous ignore directives.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // Actually this line is valid since `export` means "used",
@@ -18,7 +18,7 @@ detects unused, superfluous ignore directives.
 export const foo = 42;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 export const foo = 42;

lint_rules/button_has_type.md

@@ -1,7 +1,7 @@
 Checks that a `<button>` JSX element has a valid `type` attribute. The default
 value is `"submit"` which is often not the desired behavior.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 <button />
@@ -11,7 +11,7 @@ value is `"submit"` which is often not the desired behavior.
 <button type={2} />
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 <button type="submit" />

lint_rules/camelcase.md

@@ -13,7 +13,7 @@ Of note:
 - This rule also applies to variables imported or exported via ES modules, but
   not to object properties of those variables
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let first_name = "Ichigo";
@@ -41,7 +41,7 @@ interface snake_case_interface {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let firstName = "Ichigo";

lint_rules/constructor_super.md

@@ -4,7 +4,7 @@ Defined constructors of derived classes (e.g. `class A extends B`) must always
 call `super()`. Classes which extend non-constructors (e.g.
 `class A extends null`) must not have a constructor.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 class A {}
@@ -30,7 +30,7 @@ class E extends null {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 class A {}

lint_rules/default_param_last.md

@@ -5,14 +5,14 @@ the function call without mapping the function inputs to different parameters
 which is confusing and error prone. Specifying them last allows them to be left
 out without changing the semantics of the other parameters.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function f(a = 2, b) {}
 function f(a = 5, b, c = 5) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function f() {}

lint_rules/eqeqeq.md

@@ -6,14 +6,14 @@ value. On the other hand `==` and `!=` do type coercion before value checking
 which can lead to unexpected results. For example `5 == "5"` is `true`, while
 `5 === "5"` is `false`.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (a == 5) {}
 if ("hello world" != input) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (a === 5) {}

lint_rules/explicit_function_return_type.md

@@ -4,7 +4,7 @@ Explicit return types have a number of advantages including easier to understand
 code and better type safety. It is clear from the signature what the return type
 of the function (if any) will be.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function someCalc() {
@@ -15,7 +15,7 @@ function anotherCalc() {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function someCalc(): number {

lint_rules/explicit_module_boundary_types.md

@@ -5,7 +5,7 @@ inputs and outputs of a module (known as the module boundary). This will make it
 very clear to any users of the module how to supply inputs and handle outputs in
 a type safe manner.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // Missing return type (e.g. void)
@@ -22,7 +22,7 @@ export function isValid() {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // Typed input parameters and return value

lint_rules/for_direction.md

@@ -5,14 +5,14 @@ infinite loops. This can occur through incorrect initialization, bad
 continuation step logic or wrong direction incrementing of the loop control
 variable.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // Infinite loop
 for (let i = 0; i < 2; i--) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 for (let i = 0; i < 2; i++) {}

lint_rules/fresh_handler_export.md

@@ -5,7 +5,7 @@ rendering happens. They are expected to be available as a named export called
 `handler`. This rule checks for when the export was incorrectly named `handlers`
 instead of `handler`.
 
-### Invalid:
+**Invalid:**
 
 ```js
 export const handlers = {
@@ -16,7 +16,7 @@ export function handlers() {}
 export async function handlers() {}
 ```
 
-### Valid:
+**Valid:**
 
 ```jsx
 export const handler = {

lint_rules/fresh_server_event_handlers.md

@@ -7,15 +7,15 @@ will have no effect.
 Note that this rule only applies to server components inside the `routes/`
 folder, not to fresh islands or any other components.
 
-### Invalid:
+**Invalid:**
 
 ```jsx
 <button onClick={() => {}} />
 <button onclick={() => {}} />
 <my-custom-element foo={() => {}} />
 ```
 
-### Valid:
+**Valid:**
 
 ```jsx
 <button />

lint_rules/getter_return.md

@@ -3,7 +3,7 @@ Requires all property getter functions to return a value
 Getter functions return the value of a property. If the function returns no
 value then this contract is broken.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let foo = {
@@ -15,7 +15,7 @@ class Person {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let foo = {

lint_rules/guard_for_in.md

@@ -4,15 +4,15 @@ Looping over objects with a `for-in` loop will include properties that are
 inherited through the prototype chain. This behavior can lead to unexpected
 items in your for loop.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 for (const key in obj) {
   foo(obj, key);
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 for (const key in obj) {

lint_rules/jsx_boolean_value.md

@@ -1,14 +1,14 @@
 Enforce a consistent JSX boolean value style. Passing `true` as the boolean
 value can be omitted with the shorthand syntax.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 const foo = <Foo isFoo={true} />;
 const foo = <Foo isFoo={false} />;
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 const foo = <Foo isFoo />;

lint_rules/jsx_curly_braces.md

@@ -1,14 +1,14 @@
 Ensure consistent use of curly braces around JSX expressions.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 const foo = <Foo foo=<div /> />;
 const foo = <Foo str={"foo"} />;
 const foo = <div>{"foo"}</div>;
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 const foo = <Foo foo={<div />} />;

lint_rules/jsx_key.md

@@ -1,7 +1,7 @@
 Ensure the `key` attribute is present when passing iterables into JSX. It allows
 frameworks to optimize checking the order of elements.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 const foo = [<div>foo</div>];
@@ -10,7 +10,7 @@ const foo = [<>foo</>];
 Array.from([1, 2, 3], () => <div />);
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 const foo = [<div key="a">foo</div>];