Description
Before You File a Documentation Request Please Confirm You Have Done The Following...
- I have looked for existing open or closed documentation requests that match my proposal.
- I have read the FAQ and my problem is not listed.
Suggested Changes
@typescript-eslint/no-dupe-class-members
The ESLint documentation for the rule says that the rule is superfluous if you use TypeScript.
According to Brad, the only reason that typescript-eslint
bothers to maintain an updated version of the rule is because some people prefer the ESLint errors over the TypeScript compiler errors. However, this reasoning is not documented anywhere, so I propose the following warning be added to the top of the page for no-dupe-class-members
:
Danger
The code problem checked by this ESLint rule is automatically checked by the TypeScript compiler. Thus, it is not recommended to turn on this rule in new TypeScript projects. You only need to enable this rule if you prefer the ESLint error messages over the TypeScript compiler error messages. (When this rule was originally written, the TypeScript compiler checks did not exist.)
@typescript-eslint/no-invalid-this
The ESLint documentation for the rule does not explicitly mention it, but this rule is superfluous if you use TypeScript with the strict
or noImplicitThis
compiler flags enabled. (The strict
flag automatically includes noImplicitThis
.)
According to Brad, the only reason that typescript-eslint
bothers to maintain an updated version of the rule is because some people prefer the ESLint errors over the TypeScript compiler errors. However, this reasoning is not documented anywhere, so I propose the following warning be added to the top of the page for no-invalid-this
(which is a slightly modified version of the warning from the previous section):
Danger
The code problem checked by this ESLint rule is automatically checked by the TypeScript compiler (as long as you have thestrict
ornoImplicitThis
compiler flags enabled). Thus, it is not recommended to turn on this rule in new TypeScript projects. You only need to enable this rule if you prefer the ESLint error messages over the TypeScript compiler error messages. (When this rule was originally written, the TypeScript compiler checks did not exist.)