Skip to content

Commit 37f34f4

Browse files
JoshuaKGoldbergJoshuaKGoldberg
authored
docs: add 'When Not To Use It' or an intentional omission notice on all rules (typescript-eslint#7447)
* docs: enforce 'When Not To Use It' on all rules * Responded to immediate feedback * Filled them all in and updated test * Remove .nx shenanigans * Mentioned areas of unsafe code too
1 parent 96abf18 commit 37f34f4

File tree

89 files changed

+385
-80
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

89 files changed

+385
-80
lines changed

‎.cspell.json

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -119,6 +119,7 @@
119119
"serializers",
120120
"Sourcegraph",
121121
"stringification",
122+
"stringifying",
122123
"stringly",
123124
"superset",
124125
"thenables",

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

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -90,4 +90,10 @@ export function foo(sn: string | number): void;
9090

9191
## When Not To Use It
9292

93-
If you don't care about the general structure of the code, then you will not need this rule.
93+
It can sometimes be useful to place overload signatures alongside other meaningful parts of a type.
94+
For example, if each of a function's overloads corresponds to a different property, you might wish to put each overloads next to its corresponding property.
95+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
96+
97+
## Related To
98+
99+
- [`unified-signatures`](./unified-signatures.md)

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

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -101,3 +101,11 @@ This matrix lists all possible option combinations and their expected results fo
101101
| `generic` | `array` | `Array<number>` | `Array<Foo & Bar>` | `readonly number[]` | `readonly (Foo & Bar)[]` |
102102
| `generic` | `array-simple` | `Array<number>` | `Array<Foo & Bar>` | `readonly number[]` | `ReadonlyArray<Foo & Bar>` |
103103
| `generic` | `generic` | `Array<number>` | `Array<Foo & Bar>` | `ReadonlyArray<number>` | `ReadonlyArray<Foo & Bar>` |
104+
105+
## When Not To Use It
106+
107+
This rule is purely a stylistic rule for maintaining consistency in your project.
108+
You can turn it off if you don't want to keep a consistent style for array types.
109+
110+
However, keep in mind that inconsistent style can harm readability in a project.
111+
We recommend picking a single option for this rule that works best for your project.

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

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -37,4 +37,6 @@ await createValue();
3737
## When Not To Use It
3838

3939
If you want to allow code to `await` non-Promise values.
40-
This is generally not preferred, but can sometimes be useful for visual consistency.
40+
For example, if your framework is in transition from one style of asynchronous code to another, it may be useful to include `await`s unnecessarily.
41+
This is generally not preferred but can sometimes be useful for visual consistency.
42+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

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

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -143,7 +143,8 @@ if (false) {
143143

144144
## When Not To Use It
145145

146-
If you want to use all of the TypeScript directives.
146+
If your project or its dependencies were not architected with strong type safety in mind, it can be difficult to always adhere to proper TypeScript semantics.
147+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
147148

148149
## Further Reading
149150

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -36,4 +36,4 @@ someCode(); // This is a comment that just happens to mention tslint
3636

3737
## When Not To Use It
3838

39-
If you are still using TSLint.
39+
If you are still using TSLint alongside ESLint.

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

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -125,3 +125,8 @@ Example configuration:
125125
]
126126
}
127127
```
128+
129+
## When Not To Use It
130+
131+
If your project is a rare one that intentionally deals with the class equivalents of primitives, it might not be worthwhile to enable the default `ban-types` options.
132+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

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

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -102,5 +102,4 @@ class Mx {
102102

103103
## When Not To Use It
104104

105-
When you have no strong preference, or do not wish to enforce a particular style
106-
for how literal values are exposed by your classes.
105+
When you have no strong preference, or do not wish to enforce a particular style for how literal values are exposed by your classes.

‎packages/eslint-plugin/docs/rules/class-methods-use-this.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -89,3 +89,8 @@ class X implements Y {
8989
property = () => {};
9090
}
9191
```
92+
93+
## When Not To Use It
94+
95+
If your project dynamically changes `this` scopes around in a way TypeScript has difficulties modeling, this rule may not be viable to use.
96+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

‎packages/eslint-plugin/docs/rules/consistent-generic-constructors.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -71,3 +71,6 @@ const set: Set<string> = new Set<string>();
7171
## When Not To Use It
7272

7373
You can turn this rule off if you don't want to enforce one kind of generic constructor style over the other.
74+
75+
However, keep in mind that inconsistent style can harm readability in a project.
76+
We recommend picking a single option for this rule that works best for your project.

‎packages/eslint-plugin/docs/rules/consistent-indexed-object-style.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -70,3 +70,11 @@ type Foo = {
7070
[key: string]: unknown;
7171
};
7272
```
73+
74+
## When Not To Use It
75+
76+
This rule is purely a stylistic rule for maintaining consistency in your project.
77+
You can turn it off if you don't want to keep a consistent style for indexed object types.
78+
79+
However, keep in mind that inconsistent style can harm readability in a project.
80+
We recommend picking a single option for this rule that works best for your project.

‎packages/eslint-plugin/docs/rules/consistent-type-assertions.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -106,3 +106,6 @@ const foo = <Foo props={{ ... } as Bar}/>;
106106
## When Not To Use It
107107

108108
If you do not want to enforce consistent type assertions.
109+
110+
However, keep in mind that inconsistent style can harm readability in a project.
111+
We recommend picking a single option for this rule that works best for your project.

‎packages/eslint-plugin/docs/rules/consistent-type-definitions.md

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -71,4 +71,11 @@ type T = { x: number };
7171

7272
## When Not To Use It
7373

74-
If you specifically want to use an interface or type literal for stylistic reasons, you can disable this rule.
74+
If you specifically want to use an interface or type literal for stylistic reasons, you can avoid this rule.
75+
76+
However, keep in mind that inconsistent style can harm readability in a project.
77+
We recommend picking a single option for this rule that works best for your project.
78+
79+
There are also subtle differences between `Record` and `interface` that can be difficult to catch statically.
80+
For example, if your project is a dependency of another project that relies on a specific type definition style, this rule may be counterproductive.
81+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

‎packages/eslint-plugin/docs/rules/consistent-type-exports.md

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -96,5 +96,10 @@ export { Button, type ButtonProps } from 'some-library';
9696

9797
## When Not To Use It
9898

99-
- If you specifically want to use both export kinds for stylistic reasons, you can disable this rule.
100-
- If you use `--isolatedModules` the compiler would error if a type is not re-exported using `export type`. If you also don't wish to enforce one style over the other, you can disable this rule.
99+
If you use `--isolatedModules` the compiler would error if a type is not re-exported using `export type`.
100+
This rule may be less useful in those cases.
101+
102+
If you specifically want to use both export kinds for stylistic reasons, or don't wish to enforce one style over the other, you can avoid this rule.
103+
104+
However, keep in mind that inconsistent style can harm readability in a project.
105+
We recommend picking a single option for this rule that works best for your project.

‎packages/eslint-plugin/docs/rules/consistent-type-imports.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -96,7 +96,10 @@ If you are using [type-aware linting](https://typescript-eslint.io/linting/typed
9696

9797
## When Not To Use It
9898

99-
- If you specifically want to use both import kinds for stylistic reasons, you can disable this rule.
99+
If you specifically want to use both import kinds for stylistic reasons, or don't wish to enforce one style over the other, you can avoid this rule.
100+
101+
However, keep in mind that inconsistent style can harm readability in a project.
102+
We recommend picking a single option for this rule that works best for your project.
100103

101104
## Related To
102105

‎packages/eslint-plugin/docs/rules/dot-notation.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -73,3 +73,10 @@ x['hello'] = 123;
7373
```
7474

7575
If the TypeScript compiler option `noPropertyAccessFromIndexSignature` is set to `true`, then the above code is always allowed, even if `allowIndexSignaturePropertyAccess` is `false`.
76+
77+
## When Not To Use It
78+
79+
If you specifically want to use both member access kinds for stylistic reasons, or don't wish to enforce one style over the other, you can avoid this rule.
80+
81+
However, keep in mind that inconsistent style can harm readability in a project.
82+
We recommend picking a single option for this rule that works best for your project.

‎packages/eslint-plugin/docs/rules/explicit-function-return-type.md

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -317,8 +317,7 @@ var bar = (function () {
317317

318318
## When Not To Use It
319319

320-
If you don't wish to prevent calling code from using function return values in unexpected ways, then
321-
you will not need this rule.
320+
If you don't find the added cost of explicitly writing function return types to be worth the visual clarity, or your project is not large enough for it to be a factor in type checking performance, then you will not need this rule.
322321

323322
## Further Reading
324323

‎packages/eslint-plugin/docs/rules/explicit-member-accessibility.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -333,7 +333,11 @@ class Animal {
333333

334334
## When Not To Use It
335335

336-
If you think defaulting to public is a good default, then you should consider using the `no-public` setting. If you want to mix implicit and explicit public members then disable this rule.
336+
If you think defaulting to public is a good default, then you should consider using the `no-public` setting.
337+
If you want to mix implicit and explicit public members then you can disable this rule.
338+
339+
However, keep in mind that inconsistent style can harm readability in a project.
340+
We recommend picking a single option for this rule that works best for your project.
337341

338342
## Further Reading
339343

‎packages/eslint-plugin/docs/rules/explicit-module-boundary-types.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -243,8 +243,12 @@ export const foo: FooType = bar => {};
243243

244244
## When Not To Use It
245245

246-
If you wish to make sure all functions have explicit return types, as opposed to only the module boundaries, you can use [explicit-function-return-type](./explicit-function-return-type.md)
246+
If your project is not used by downstream consumers that are sensitive to API types, you can disable this rule.
247247

248248
## Further Reading
249249

250250
- TypeScript [Functions](https://www.typescriptlang.org/docs/handbook/functions.html#function-types)
251+
252+
## Related To
253+
254+
- [explicit-function-return-type](./explicit-function-return-type.md)

‎packages/eslint-plugin/docs/rules/member-delimiter-style.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -158,4 +158,7 @@ type FooBar = { name: string; greet(): string }
158158
159159
## When Not To Use It
160160
161-
If you don't care about enforcing a consistent member delimiter in interfaces and type literals, then you will not need this rule.
161+
If you specifically want to use both member delimiter kinds for stylistic reasons, or don't wish to enforce one style over the other, you can avoid this rule.
162+
163+
However, keep in mind that inconsistent style can harm readability in a project.
164+
We recommend picking a single option for this rule that works best for your project.

‎packages/eslint-plugin/docs/rules/method-signature-style.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -108,3 +108,6 @@ type T2 = {
108108
## When Not To Use It
109109

110110
If you don't want to enforce a particular style for object/interface function types, and/or if you don't use `strictFunctionTypes`, then you don't need this rule.
111+
112+
However, keep in mind that inconsistent style can harm readability in a project.
113+
We recommend picking a single option for this rule that works best for your project.

‎packages/eslint-plugin/docs/rules/naming-convention.md

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -711,4 +711,11 @@ You can use the `destructured` modifier to match these names, and explicitly set
711711

712712
## When Not To Use It
713713

714-
If you do not want to enforce naming conventions for anything.
714+
This rule can be very strict.
715+
If you don't have strong needs for enforcing naming conventions, we recommend using it only to flag very egregious violations of your naming standards.
716+
Consider documenting your naming conventions and enforcing them in code review if you have processes like that.
717+
718+
If you do not want to enforce naming conventions for anything, you can disable this rule.
719+
720+
However, keep in mind that inconsistent style can harm readability in a project.
721+
We recommend that if you care about naming conventions, pick a single option for this rule that works best for your project.

‎packages/eslint-plugin/docs/rules/no-base-to-string.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -76,7 +76,7 @@ let text = `${value}`;
7676

7777
## When Not To Use It
7878

79-
If you don't mind `"[object Object]"` in your strings, then you will not need this rule.
79+
If you don't mind a risk of `"[object Object]"` or incorrect type coercions in your values, then you will not need this rule.
8080

8181
## Related To
8282

‎packages/eslint-plugin/docs/rules/no-confusing-void-expression.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -113,4 +113,4 @@ console.log(void alert('Hello, world!'));
113113

114114
The return type of a function can be inspected by going to its definition or hovering over it in an IDE.
115115
If you don't care about being explicit about the void type in actual code then don't use this rule.
116-
Also, if you prefer concise coding style then also don't use it.
116+
Also, if you strongly prefer a concise coding style more strongly than any fear of `void`-related bugs then you can avoid this rule.

‎packages/eslint-plugin/docs/rules/no-duplicate-enum-values.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -48,3 +48,11 @@ enum E {
4848
B = 'B',
4949
}
5050
```
51+
52+
## When Not To Use It
53+
54+
It can sometimes be useful to include duplicate enum members for very specific use cases.
55+
For example, when renaming an enum member, it can sometimes be useful to keep the old name until a scheduled major breaking change.
56+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
57+
58+
In general, if your project intentionally duplicates enum member values, you can avoid this rule.

‎packages/eslint-plugin/docs/rules/no-duplicate-type-constituents.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -57,3 +57,10 @@ When set to true, duplicate checks on intersection type constituents are ignored
5757
### `ignoreUnions`
5858

5959
When set to true, duplicate checks on union type constituents are ignored.
60+
61+
## When Not To Use It
62+
63+
It can sometimes be useful for the sake of documentation to include aliases for the same type.
64+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
65+
66+
> In some of those cases, [branded types](https://basarat.gitbook.io/typescript/main-1/nominaltyping#using-interfaces) might be a type-safe way to represent the underlying data types.

‎packages/eslint-plugin/docs/rules/no-dynamic-delete.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -47,7 +47,7 @@ delete container['-Infinity'];
4747
## When Not To Use It
4848

4949
When you know your keys are safe to delete, this rule can be unnecessary.
50-
Some environments such as older browsers might not support `Map` and `Set`.
50+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
5151

5252
Do not consider this rule as performance advice before profiling your code's bottlenecks.
5353
Even repeated minor performance slowdowns likely do not significantly affect your application's general perceived speed.

‎packages/eslint-plugin/docs/rules/no-empty-function.md

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -84,3 +84,12 @@ class Foo extends Base {
8484
protected override greet(): void {}
8585
}
8686
```
87+
88+
## When Not To Use It
89+
90+
If you are working with external APIs that require functions even if they do nothing, then you may want to avoid this rule.
91+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
92+
93+
Test code often violates this rule as well.
94+
If your testing setup doesn't support "mock" or "spy" functions such as [`jest.fn()`](https://jestjs.io/docs/mock-functions), [`sinon.spy()`](https://sinonjs.org/releases/latest/spies), or [`vi.fn()`](https://vitest.dev/guide/mocking.html), you may wish to disable this rule in test files.
95+
Again, if those cases aren't extremely common, you might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule in test files.

‎packages/eslint-plugin/docs/rules/no-explicit-any.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -138,6 +138,8 @@ Most commonly:
138138
- If an external package doesn't yet have typings and you want to use `any` pending adding a `.d.ts` for it
139139
- You're working with particularly complex or nuanced code that can't yet be represented in the TypeScript type system
140140

141+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
142+
141143
## Related To
142144

143145
- [`no-unsafe-argument`](./no-unsafe-argument.md)
@@ -148,5 +150,7 @@ Most commonly:
148150

149151
## Further Reading
150152

153+
- TypeScript [`any` type](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any)
154+
- TypeScript's [`unknown` type](https://www.typescriptlang.org/docs/handbook/2/functions.html#unknown)
151155
- TypeScript [`any` type documentation](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any)
152156
- TypeScript [`unknown` type release notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type)

‎packages/eslint-plugin/docs/rules/no-extra-non-null-assertion.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -50,3 +50,5 @@ function foo(bar?: { n: number }) {
5050
return bar?.n;
5151
}
5252
```
53+
54+
<!-- Intentionally Omitted: When Not To Use It -->

‎packages/eslint-plugin/docs/rules/no-extraneous-class.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -291,4 +291,5 @@ class Constants {
291291

292292
## When Not To Use It
293293

294-
You can disable this rule if you are unable -or unwilling- to switch off using classes as namespaces.
294+
If your project was set up before modern class and namespace practices, and you don't have the time to switch over, you might not be practically able to use this rule.
295+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

‎packages/eslint-plugin/docs/rules/no-floating-promises.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,9 @@ await(async function () {
9999

100100
## When Not To Use It
101101

102-
If you do not use Promise-like values in your codebase, or want to allow them to remain unhandled.
102+
This rule can be difficult to enable on large existing projects that set up many floating Promises.
103+
Alternately, if you're not worried about crashes from floating or misused Promises -such as if you have global unhandled Promise handlers registered- then in some cases it may be safe to not use this rule.
104+
You might consider using `void`s and/or [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
103105

104106
## Related To
105107

‎packages/eslint-plugin/docs/rules/no-for-in-array.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -53,4 +53,5 @@ for (const [i, value] of array.entries()) {
5353

5454
## When Not To Use It
5555

56-
If you want to iterate through a loop using the indices in an array as strings, you can turn off this rule.
56+
If your project is a rare one that intentionally loops over string indices of arrays, you can turn off this rule.
57+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

‎packages/eslint-plugin/docs/rules/no-implied-eval.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -98,4 +98,5 @@ setTimeout(Foo.fn, 100);
9898

9999
## When Not To Use It
100100

101-
If you want to allow `new Function()` or `setTimeout()`, `setInterval()`, `setImmediate()` and `execScript()` with string arguments, then you can safely disable this rule.
101+
If your project is a rare one that needs to allow `new Function()` or `setTimeout()`, `setInterval()`, `setImmediate()` and `execScript()` with string arguments, then you can disable this rule.
102+
You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

‎packages/eslint-plugin/docs/rules/no-import-type-side-effects.md

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -65,8 +65,7 @@ import T, { type U } from 'mod';
6565

6666
## When Not To Use It
6767

68-
- If you want to leave behind side effect imports, then you shouldn't use this rule.
69-
- If you're not using TypeScript 5.0's `verbatimModuleSyntax` option, then you don't need this rule.
68+
If you're not using TypeScript 5.0's `verbatimModuleSyntax` option and your project is built with a bundler that manages import side effects for you, this rule may not be as useful for you.
7069

7170
## Related To
7271

‎packages/eslint-plugin/docs/rules/no-inferrable-types.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -96,8 +96,8 @@ class Foo {
9696

9797
## When Not To Use It
9898

99-
If you do not want to enforce inferred types.
99+
If you strongly prefer to have explicit types regardless of whether they can be inferred, this rule may not be for you.
100100

101101
## Further Reading
102102

103-
TypeScript [Inference](https://www.typescriptlang.org/docs/handbook/type-inference.html)
103+
- [TpeScript Inference](https://www.typescriptlang.org/docs/handbook/type-inference.html)

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy