it might be worth looking at https://github.com/mysticatea/eslint-plugin-eslint-comments
It does a similar thing except with eslint comments.

Glancing at that code makes me suspect this is something we can't handle purely within the plugin?

Just spitballing: It seems like it could be possible if TSC includes all errors/warnings, including the ignored warnings under a different object property. Then it would be easy to check those warnings' locations against the TS ignore comments and see if any of the ignore comments have no corresponding warnings. But not sure if that's the intended/ideal direction, or if TSC should be handling this.

The problem there is that we don't attach comments to nodes, and eslint deprecated the functionality to do that. #158 (comment)

So whilst we know about the comments, we don't know what node they're attached to (unless tsc exposes that information). This means we don't know which node to check for errors (even if tsc did surface the ignored errors for us).

For that reason alone, I would say that this rule would be non-trivial to implement.

@bradzacher You wouldn't need to use comment attachment- you would just need to compare range or location information. That said, I agree that this would, in general, not be trivial to implement.

//@ts-ignore comments ignore all type errors on next line. Something like this is possible:

// @ts-ignore
let a: string = 1; let b: number = 'str'

I agree with @platinumazure that TSC should provide information about ignored diagnostics so we can cross check them with the comments. Made an issue for that in TypeScript:
microsoft/TypeScript#29843

Relevant: microsoft/TypeScript#36014 will add a // @ts-expect-error to TypeScript. We could make this rule instead just ban // @ts-ignore altogether.

Edit: I just noticed ban-ts-comment already does that! 😄

It's already a rule (as of a week or so)! Just missed this issue.
https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/ban-ts-comment.md

This is different than what I suggest. I wanted to make sure we don’t have dead ts-ignore directives. Banning it altogether is not the same.

This is useful when you have an issue that you can’t resolve and you use ts ignore to surpass it but then later via some mechanism like dependency update the type error is no longer there but the ts-ignore comment is there and it doesn’t allow ts to check the next line.

Relevant ts issues:
microsoft/TypeScript#29394
microsoft/TypeScript#25166

pr: microsoft/TypeScript#36014

This can be closed now, as microsoft/TypeScript#36014 has been merged, and will be released as part of the next TS version.

You'll have to migrate your codebases to use ts-expect-error when it's released, and then any comments that don't cause a TS error will themselves cause a TS error.