xo 0.52.4 → 0.53.0

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-declaration-merging.md

@@ -0,0 +1,54 @@
+---
+description: 'Disallow unsafe declaration merging.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-unsafe-declaration-merging** for documentation.
+
+TypeScript's "declaration merging" supports merging separate declarations with the same name.
+
+Declaration merging between classes and interfaces is unsafe.
+The TypeScript compiler doesn't check whether properties are initialized, which can cause lead to TypeScript not detecting code that will cause runtime errors.
+
+```ts
+interface Foo {
+  nums: number[];
+}
+
+class Foo {}
+
+const foo = new Foo();
+
+foo.nums.push(1); // Runtime Error: Cannot read properties of undefined.
+```
+
+## Examples
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+interface Foo {}
+
+class Foo {}
+```
+
+### ✅ Correct
+
+```ts
+interface Foo {}
+class Bar implements Foo {}
+
+namespace Baz {}
+namespace Baz {}
+enum Baz {}
+
+namespace Qux {}
+function Qux() {}
+```
+
+## Further Reading
+
+- [Declaration Merging](https://www.typescriptlang.org/docs/handbook/declaration-merging.html)

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-member-access.md

@@ -6,14 +6,15 @@ description: 'Disallow member access on a value with type `any`.'
 >
 > See **https://typescript-eslint.io/rules/no-unsafe-member-access** for documentation.
 
-Despite your best intentions, the `any` type can sometimes leak into your codebase.
-Member access on `any` typed variables is not checked at all by TypeScript, so it creates a potential safety hole, and source of bugs in your codebase.
+The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
+Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
 
-## Rule Details
+Despite your best intentions, the `any` type can sometimes leak into your codebase.
+Accessing a member of an `any`-typed value creates a potential type safety hole and source of bugs in your codebase.
 
 This rule disallows member access on any variable that is typed as `any`.
 
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-return.md

@@ -6,15 +6,18 @@ description: 'Disallow returning a value with type `any` from a function.'
 >
 > See **https://typescript-eslint.io/rules/no-unsafe-return** for documentation.
 
-Despite your best intentions, the `any` type can sometimes leak into your codebase.
-Returned `any` typed values are not checked at all by TypeScript, so it creates a potential safety hole, and source of bugs in your codebase.
+The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
+Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
 
-## Rule Details
+Despite your best intentions, the `any` type can sometimes leak into your codebase.
+Returning an an `any`-typed value from a function creates a potential type safety hole and source of bugs in your codebase.
 
 This rule disallows returning `any` or `any[]` from a function.
-This rule also compares the return type to the function's declared/inferred return type to ensure you don't return an unsafe `any` in a generic position to a receiver that's expecting a specific type. For example, it will error if you return `Set<any>` from a function declared as returning `Set<string>`.
 
-Examples of code for this rule:
+This rule also compares generic type argument types to ensure you don't return an unsafe `any` in a generic position to a function that's expecting a specific type.
+For example, it will error if you return `Set<any>` from a function declared as returning `Set<string>`.
+
+## Examples
 
 <!--tabs-->
 
@@ -83,7 +86,7 @@ const assignability2: TAssign = () => new Set(['foo']);
 
 There are cases where the rule allows to return `any` to `unknown`.
 
-Examples of `any` to `unknown` return that are allowed.
+Examples of `any` to `unknown` return that are allowed:
 
 ```ts
 function foo1(): unknown {

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unused-expressions.md

@@ -6,7 +6,7 @@ description: 'Disallow unused expressions.'
 >
 > See **https://typescript-eslint.io/rules/no-unused-expressions** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/no-unused-expressions`](https://eslint.org/docs/rules/no-unused-expressions) rule.
 It adds support for optional call expressions `x?.()`, and directive in module declarations.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unused-vars.md

@@ -6,7 +6,7 @@ description: 'Disallow unused variables.'
 >
 > See **https://typescript-eslint.io/rules/no-unused-vars** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/no-unused-vars`](https://eslint.org/docs/rules/no-unused-vars) rule.
 It adds support for TypeScript features, such as types.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-use-before-define.md

@@ -6,7 +6,7 @@ description: 'Disallow the use of variables before they are defined.'
 >
 > See **https://typescript-eslint.io/rules/no-use-before-define** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/no-use-before-define`](https://eslint.org/docs/rules/no-use-before-define) rule.
 It adds support for `type`, `interface` and `enum` declarations.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-useless-constructor.md

@@ -6,7 +6,7 @@ description: 'Disallow unnecessary constructors.'
 >
 > See **https://typescript-eslint.io/rules/no-useless-constructor** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/no-useless-constructor`](https://eslint.org/docs/rules/no-useless-constructor) rule.
 It adds support for:

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-useless-empty-export.md

@@ -6,17 +6,17 @@ description: "Disallow empty exports that don't change anything in a module file
 >
 > See **https://typescript-eslint.io/rules/no-useless-empty-export** for documentation.
 
-## Rule Details
-
 An empty `export {}` statement is sometimes useful in TypeScript code to turn a file that would otherwise be a script file into a module file.
-Per the TypeScript Handbook [Modules](https://www.typescriptlang.org/docs/handbook/modules.html) page:
+Per the [TypeScript Handbook Modules page](https://www.typescriptlang.org/docs/handbook/modules.html):
 
 > In TypeScript, just as in ECMAScript 2015, any file containing a top-level import or export is considered a module.
 > Conversely, a file without any top-level import or export declarations is treated as a script whose contents are available in the global scope (and therefore to modules as well).
 
 However, an `export {}` statement does nothing if there are any other top-level import or export statements in a file.
 
-Examples of code for this rule:
+This rule reports an `export {}` that doesn't do anything in a file already using ES modules.
+
+## Examples
 
 <!--tabs-->
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-var-requires.md

@@ -8,9 +8,7 @@ description: 'Disallow `require` statements except in import statements.'
 
 In other words, the use of forms such as `var foo = require("foo")` are banned. Instead use ES6 style imports or `import foo = require("foo")` imports.
 
-## Rule Details
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
@@ -32,4 +30,8 @@ import foo from 'foo';
 
 ## When Not To Use It
 
-If you don't care about TypeScript module syntax, then you will not need this rule.
+If you don't care about using newer module syntax, then you will not need this rule.
+
+## Related To
+
+- [`no-require-imports`](./no-require-imports.md)

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/non-nullable-type-assertion-style.md

@@ -6,11 +6,15 @@ description: 'Enforce non-null assertions over explicit type casts.'
 >
 > See **https://typescript-eslint.io/rules/non-nullable-type-assertion-style** for documentation.
 
-This rule detects when an `as` cast is doing the same job as a `!` would, and suggests fixing the code to be an `!`.
+There are two common ways to assert to TypeScript that a value is its type without `null` or `undefined`:
 
-## Rule Details
+- `!`: Non-null assertion
+- `as`: Traditional type assertion with a coincidentally equivalent type
 
-Examples of code for this rule:
+`!` non-null assertions are generally preferred for requiring less code and being harder to fall out of sync as types change.
+This rule reports when an `as` cast is doing the same job as a `!` would, and suggests fixing the code to be an `!`.
+
+## Examples
 
 <!--tabs-->
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/object-curly-spacing.md

@@ -6,7 +6,7 @@ description: 'Enforce consistent spacing inside braces.'
 >
 > See **https://typescript-eslint.io/rules/object-curly-spacing** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/object-curly-spacing`](https://eslint.org/docs/rules/object-curly-spacing) rule.
 It adds support for TypeScript's object types.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/padding-line-between-statements.md

@@ -6,7 +6,7 @@ description: 'Require or disallow padding lines between statements.'
 >
 > See **https://typescript-eslint.io/rules/padding-line-between-statements** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/padding-line-between-statements`](https://eslint.org/docs/rules/padding-line-between-statements) rule.
 It adds support for TypeScript constructs such as `interface` and `type`.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/parameter-properties.md

@@ -6,13 +6,10 @@ description: 'Require or disallow parameter properties in class constructors.'
 >
 > See **https://typescript-eslint.io/rules/parameter-properties** for documentation.
 
-Parameter properties can be confusing to those new to TypeScript as they are less explicit than other ways
-of declaring and initializing class members.
+TypeScript includes a "parameter properties" shorthand for declaring a class constructor parameter and class property in one location.
+Parameter properties can be confusing to those new to TypeScript as they are less explicit than other ways of declaring and initializing class members.
 
-## Rule Details
-
-This rule disallows the use of parameter properties in constructors, forcing the user to explicitly
-declare all properties in the class.
+This rule can be configured to always disallow the use of parameter properties or enforce their usage when possible.
 
 ## Options
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-as-const.md

@@ -6,11 +6,15 @@ description: 'Enforce the use of `as const` over literal type.'
 >
 > See **https://typescript-eslint.io/rules/prefer-as-const** for documentation.
 
-This rule recommends usage of `const` assertion when type primitive value is equal to type.
+There are two common ways to tell TypeScript that a literal value should be interpreted as its literal type (e.g. `2`) rather than general primitive type (e.g. `number`);
 
-## Rule Details
+- `as const`: telling TypeScript to infer the literal type automatically
+- `as` with the literal type: explicitly telling the literal type to TypeScript
 
-Examples of code for this rule:
+`as const` is generally preferred, as it doesn't require re-typing the literal value.
+This rule reports when an `as` with an explicit literal type can be replaced with an `as const`.
+
+## Examples
 
 <!--tabs-->
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-enum-initializers.md

@@ -6,32 +6,14 @@ description: 'Require each enum member value to be explicitly initialized.'
 >
 > See **https://typescript-eslint.io/rules/prefer-enum-initializers** for documentation.
 
-This rule recommends having each `enum`s member value explicitly initialized.
+TypeScript `enum`s are a practical way to organize semantically related constant values.
+Members of `enum`s that don't have explicit values are by default given sequentially increasing numbers.
 
-`enum`s are a practical way to organize semantically related constant values. However, by implicitly defining values, `enum`s can lead to unexpected bugs if it's modified without paying attention to the order of its items.
+In projects where the value of `enum` members are important, allowing implicit values for enums can cause bugs if `enum`s are modified over time.
 
-## Rule Details
+This rule recommends having each `enum` member value explicitly initialized.
 
-`enum`s infers sequential numbers automatically when initializers are omitted:
-
-```ts
-enum Status {
-  Open, // infer 0
-  Closed, // infer 1
-}
-```
-
-If a new member is added to the top of `Status`, both `Open` and `Closed` would have its values altered:
-
-```ts
-enum Status {
-  Pending, // infer 0
-  Open, // infer 1
-  Closed, // infer 2
-}
-```
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-for-of.md

@@ -6,39 +6,38 @@ description: 'Enforce the use of `for-of` loop over the standard `for` loop wher
 >
 > See **https://typescript-eslint.io/rules/prefer-for-of** for documentation.
 
-This rule recommends a for-of loop when the loop index is only used to read from an array that is being iterated.
-
-## Rule Details
+Many developers default to writing `for (let i = 0; i < ...` loops to iterate over arrays.
+However, in many of those arrays, the loop iterator variable (e.g. `i`) is only used to access the respective element of the array.
+In those cases, a `for-of` loop is easier to read and write.
 
-For cases where the index is only used to read from the array being iterated, a for-of loop is easier to read and write.
+This rule recommends a for-of loop when the loop index is only used to read from an array that is being iterated.
 
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
 ### ❌ Incorrect
 
 ```js
-for (let i = 0; i < arr.length; i++) {
-  console.log(arr[i]);
+declare const array: string[];
+
+for (let i = 0; i < array.length; i++) {
+  console.log(array[i]);
 }
 ```
 
 ### ✅ Correct
 
 ```js
-for (const x of arr) {
-  console.log(x);
-}
+declare const array: string[];
 
-for (let i = 0; i < arr.length; i++) {
-  // i is used to write to arr, so for-of could not be used.
-  arr[i] = 0;
+for (const x of array) {
+  console.log(x);
 }
 
-for (let i = 0; i < arr.length; i++) {
-  // i is used independent of arr, so for-of could not be used.
-  console.log(i, arr[i]);
+for (let i = 0; i < array.length; i++) {
+  // i is used, so for-of could not be used.
+  console.log(i, array[i]);
 }
 ```
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-function-type.md

@@ -6,36 +6,35 @@ description: 'Enforce using function types instead of interfaces with call signa
 >
 > See **https://typescript-eslint.io/rules/prefer-function-type** for documentation.
 
-## Rule Details
+TypeScript allows for two common ways to declare a type for a function:
+
+- Function type: `() => string`
+- Object type with a signature: `{ (): string }`
+
+The function type form is generally preferred when possible for being more succinct.
 
 This rule suggests using a function type instead of an interface or object type literal with a single call signature.
 
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
 ### ❌ Incorrect
 
 ```ts
-interface Foo {
+interface Example {
   (): string;
 }
 ```
 
 ```ts
-function foo(bar: { (): number }): number {
-  return bar();
-}
-```
-
-```ts
-interface Foo extends Function {
-  (): void;
+function foo(example: { (): number }): number {
+  return example();
 }
 ```
 
 ```ts
-interface MixinMethod {
+interface ReturnsSelf {
   // returns the function itself, not the `this` argument.
   (arg: string): this;
 }
@@ -44,12 +43,20 @@ interface MixinMethod {
 ### ✅ Correct
 
 ```ts
-interface Foo {
-  (): void;
-  bar: number;
+type Example = () => string;
+```
+
+```ts
+function foo(example: () => number): number {
+  return bar();
 }
 ```
 
+```ts
+// returns the function itself, not the `this` argument.
+type ReturnsSelf = (arg: string) => ReturnsSelf;
+```
+
 ```ts
 function foo(bar: { (): string; baz: number }): string {
   return bar();
@@ -65,13 +72,6 @@ interface Bar extends Foo {
 }
 ```
 
-```ts
-// returns the `this` argument of function, retaining it's type.
-type MixinMethod = <TSelf>(this: TSelf, arg: string) => TSelf;
-// a function that returns itself is much clearer in this form.
-type ReturnsSelf = (arg: string) => ReturnsSelf;
-```
-
 ```ts
 // multiple call signatures (overloads) is allowed:
 interface Overloaded {

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-includes.md

@@ -6,34 +6,28 @@ description: 'Enforce `includes` method over `indexOf` method.'
 >
 > See **https://typescript-eslint.io/rules/prefer-includes** for documentation.
 
-Until ES5, we were using `String#indexOf` method to check whether a string contains an arbitrary substring or not.
-Until ES2015, we were using `Array#indexOf` method to check whether an array contains an arbitrary value or not.
-
-ES2015 has added `String#includes` and ES2016 has added `Array#includes`.
-It makes code more understandable if we use those `includes` methods for the purpose.
-
-## Rule Details
-
-This rule is aimed at suggesting `includes` method if `indexOf` method was used to check whether an object contains an arbitrary value or not.
-
-If the receiver object of the `indexOf` method call has `includes` method and the two methods have the same parameters, this rule does suggestion.
-There are such types: `String`, `Array`, `ReadonlyArray`, and typed arrays.
+Prior to ES2015, `Array#indexOf` and `String#indexOf` comparisons against `-1` were the standard ways to check whether a value exists in an array or string, respectively.
+Alternatives that are easier to read and write now exist: ES2015 added `String#includes` and ES2016 added `Array#includes`.
 
+This rule reports when an `.indexOf` call can be replaced with an `.includes`.
 Additionally, this rule reports the tests of simple regular expressions in favor of `String#includes`.
 
-Examples of code for this rule:
+> This rule will report on any receiver object of an `indexOf` method call that has an `includes` method where the two methods have the same parameters.
+> Matching types include: `String`, `Array`, `ReadonlyArray`, and typed arrays.
+
+## Examples
 
 <!--tabs-->
 
 ### ❌ Incorrect
 
 ```ts
-let str: string;
-let array: any[];
-let readonlyArray: ReadonlyArray<any>;
-let typedArray: UInt8Array;
-let maybe: string;
-let userDefined: {
+const str: string;
+const array: any[];
+const readonlyArray: ReadonlyArray<any>;
+const typedArray: UInt8Array;
+const maybe: string;
+const userDefined: {
   indexOf(x: any): number;
   includes(x: any): boolean;
 };
@@ -45,32 +39,36 @@ typedArray.indexOf(value) > -1;
 maybe?.indexOf('') !== -1;
 userDefined.indexOf(value) >= 0;
 
-// simple RegExp test
-/foo/.test(str);
+/example/.test(str);
 ```
 
 ### ✅ Correct
 
 ```ts
-let array: any[];
-let readonlyArray: ReadonlyArray<any>;
-let typedArray: UInt8Array;
-let userDefined: {
+const str: string;
+const array: any[];
+const readonlyArray: ReadonlyArray<any>;
+const typedArray: UInt8Array;
+const maybe: string;
+const userDefined: {
   indexOf(x: any): number;
   includes(x: any): boolean;
 };
-let mismatchExample: {
-  indexOf(x: any, fromIndex?: number): number;
-  includes(x: any): boolean;
-};
 
 str.includes(value);
 array.includes(value);
 readonlyArray.includes(value);
 typedArray.includes(value);
+maybe?.includes('');
 userDefined.includes(value);
 
-// the two methods have different parameters.
+str.includes('example');
+
+// The two methods have different parameters.
+declare const mismatchExample: {
+  indexOf(x: unknown, fromIndex?: number): number;
+  includes(x: unknown): boolean;
+};
 mismatchExample.indexOf(value) >= 0;
 ```
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-literal-enum-member.md

@@ -6,7 +6,9 @@ description: 'Require all enum members to be literal values.'
 >
 > See **https://typescript-eslint.io/rules/prefer-literal-enum-member** for documentation.
 
-TypeScript allows the value of an enum member to be many different kinds of valid JavaScript expressions. However, because enums create their own scope whereby each enum member becomes a variable in that scope, unexpected values could be used at runtime. Example:
+TypeScript allows the value of an enum member to be many different kinds of valid JavaScript expressions.
+However, because enums create their own scope whereby each enum member becomes a variable in that scope, developers are often surprised at the resultant values.
+For example:
 
 ```ts
 const imOutside = 2;
@@ -21,17 +23,12 @@ enum Foo {
 }
 ```
 
-The answer is that `Foo.c` will be `1` at runtime. The [playground](https://www.typescriptlang.org/play/#src=const%20imOutside%20%3D%202%3B%0D%0Aconst%20b%20%3D%202%3B%0D%0Aenum%20Foo%20%7B%0D%0A%20%20%20%20outer%20%3D%20imOutside%2C%0D%0A%20%20%20%20a%20%3D%201%2C%0D%0A%20%20%20%20b%20%3D%20a%2C%0D%0A%20%20%20%20c%20%3D%20b%2C%0D%0A%20%20%20%20%2F%2F%20does%20c%20%3D%3D%20Foo.b%20%3D%3D%20Foo.c%20%3D%3D%201%3F%0D%0A%20%20%20%20%2F%2F%20or%20does%20c%20%3D%3D%20b%20%3D%3D%202%3F%0D%0A%7D) illustrates this quite nicely.
+> The answer is that `Foo.c` will be `1` at runtime [[TypeScript playground](https://www.typescriptlang.org/play/#src=const%20imOutside%20%3D%202%3B%0D%0Aconst%20b%20%3D%202%3B%0D%0Aenum%20Foo%20%7B%0D%0A%20%20%20%20outer%20%3D%20imOutside%2C%0D%0A%20%20%20%20a%20%3D%201%2C%0D%0A%20%20%20%20b%20%3D%20a%2C%0D%0A%20%20%20%20c%20%3D%20b%2C%0D%0A%20%20%20%20%2F%2F%20does%20c%20%3D%3D%20Foo.b%20%3D%3D%20Foo.c%20%3D%3D%201%3F%0D%0A%20%20%20%20%2F%2F%20or%20does%20c%20%3D%3D%20b%20%3D%3D%202%3F%0D%0A%7D)].
 
-## Rule Details
+Therefore, it's often better to prevent unexpected results in code by requiring the use of literal values as enum members.
+This rule reports when an enum member is given a value that is not a literal.
 
-This rule is meant to prevent unexpected results in code by requiring the use of literal values as enum members to prevent unexpected runtime behavior. Template literals, arrays, objects, constructors, and all other expression types can end up using a variable from its scope or the parent scope, which can result in the same unexpected behavior at runtime.
-
-## Options
-
-- `allowBitwiseExpressions` set to `true` will allow you to use bitwise expressions in enum initializer (Default: `false`).
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
@@ -62,13 +59,15 @@ enum Valid {
 
 <!--/tabs-->
 
-### `allowBitwiseExpressions`
+## Options
+
+- `allowBitwiseExpressions` set to `true` will allow you to use bitwise expressions in enum initializer (Default: `false`).
 
 Examples of code for the `{ "allowBitwiseExpressions": true }` option:
 
 <!--tabs-->
 
-#### ❌ Incorrect
+### ❌ Incorrect
 
 ```ts
 const x = 1;
@@ -83,7 +82,7 @@ enum Foo {
 }
 ```
 
-#### ✅ Correct
+### ✅ Correct
 
 ```ts
 enum Foo {

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-namespace-keyword.md

@@ -6,12 +6,35 @@ description: 'Require using `namespace` keyword over `module` keyword to declare
 >
 > See **https://typescript-eslint.io/rules/prefer-namespace-keyword** for documentation.
 
-In an effort to prevent further confusion between custom TypeScript modules and the new ES2015 modules, starting
-with TypeScript `v1.5` the keyword `namespace` is now the preferred way to declare custom TypeScript modules.
+TypeScript historically allowed a form of code organization called "custom modules" (`module Example {}`), later renamed to "namespaces" (`namespace Example`).
 
-## Rule Details
+Namespaces are an outdated way to organize TypeScript code.
+ES2015 module syntax is now preferred (`import`/`export`).
 
-This rule aims to standardize the way modules are declared.
+For projects still using custom modules / namespaces, it's preferred to refer to them as namespaces.
+This rule reports when the `module` keyword is used instead of `namespace`.
+
+> This rule does not report on the use of TypeScript module declarations to describe external APIs (`declare module 'foo' {}`).
+
+## Examples
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+module Example {}
+```
+
+### ✅ Correct
+
+```ts
+namespace Example {}
+
+declare module 'foo' {}
+```
+
+<!--/tabs-->
 
 ## When Not To Use It