Typescript: Report unneeded @ts-ignore directives that do nothing

[ide]

Search Terms

unnecessary @ts-ignore suppression

Suggestion

This is a feature request to have TypeScript report a warning or error when a @ts-ignore comment does not suppress any error. This way, when developers fix previously suppressed errors by changing their code, upgrading their version of TypeScript, or upgrading their type declarations, they can easily remove the @ts-ignore directives that are no longer needed. This should give them a little more type-checking coverage and remove no-longer-accurate comments.

To maintain backwards-compatibility and not introduce new errors into existing codebases, this could be enabled by a flag in tsconfig.json (ex: noUnusedIgnores). Flow does something similar already with $FlowIgnore. My apologies if this feature has already been discussed. I searched several different keywords and didn't see an existing issue.

Use Cases

As mentioned above, developers may (inadvertently) fix type errors that were previously suppressed by upgrading TypeScript (ex: if a newer version of TS fixes a bug), upgrading a type declaration (ex: if a new DefinitelyTyped package has improved types, which is common), or if changes to one part of the codebase affect type checking in another. This feature would help developers remove the now-unneeded @ts-config comments.

Examples

This would result in an error, since let x = 1; doesn't produce any warnings or errors.

// @ts-ignore
let x = 1;

This, however, would not result in an error, since let x: string = 1; would produce an error without the suppression:

// @ts-ignore
let x: string = 1;

Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. new expression-level syntax)

[Swatinem]

Also see https://github.com/palantir/tslint/issues/3975 which I opened a few days ago.

[giladgray]

This feature definitely belongs in TypeScript itself, not in the linter.

[RyanCavanaugh]

Why not just have a separate tool that strips out all ignore comments that don't do anything?

[ide]

Why not just have a separate tool that strips out all ignore comments that don't do anything?

From a technical perspective I imagine a separate tool would work mostly fine, especially if it could get the syntax tree from TypeScript and the errors associated with each node. One technical reason to include this tool in TypeScript is that the semantics of @ts-ignore would live in one place. If TypeScript changed @ts-ignore to apply to different parts of the code or added a new type of ignore directive, then this separate tool might need to update its own re-implementation of ignore directives depending on how the tool is implemented.

The more compelling reason IMO is that by including this feature in tsc and making it easy to use, more people will remove stale comments and increase their type-checking coverage a bit. This seems good for individual codebases and the general TypeScript ecosystem in its own small way. And I imagine the feature itself (vs. how it's implemented) not to be very controversial. But I'm not familiar with the TypeScript codebase itself nor am one of the people responsible for maintaining it so I can't speak much to the burdens and risks of including this feature in tsc and whether it's worth spending time writing it or taking on the maintenance cost of a potential PR.

[giladgray]

One technical reason to include this tool in TypeScript is that the semantics of @ts-ignore would live in one place

👏 👏 👏

why would this feature _not_ belong in TypeScript itself?

[0rvar]

What's the status on this? I think it's a great idea. Flow warns against unnecessary suppression comments

[ide]

Presumably the status hasn't changed from a year ago since there haven't been any updates on this issue. If it were actually important someone would probably have written / gotten someone to write a good PR for it. It's probably not hard to implement (naively said without having read the code).

[ide]

Closing this because it has been implemented as @ts-expect-error in 3.9.