consider using new allow-with-description options for ts-ignore and ts-expect-error

[dimitropoulos]

Context

Recently I contributed a change to @typescript-eslint that I think the maintainers of this project may have interest in.

Basically, it's an option that mandates that any time someone uses a ts-ignore or ts-expect-error directive, it's followed with a comment explaining why the line needed to be disabled. You can also configure the minimum number of characters that will satisfy the rule (i.e. to encourage people to not just do // @ts-ignore todo, but instead say a little more).

Suggestion

Turning on this rule as shown.

Side Notes/Observations:

1. There are a few places where ts-ignore-next-line or similar is used. The -next-line portion is actually ignored by TypeScript. The only kind of directive you can give is one that affects the next non-commented line.
   

2. Whenever the project is updated to TypeScript 3.9, I bet you'll want to banish all uses of ts-ignore and switch them to the new/improved/fancy/better ts-expect-error anyway, so maybe now is a good time to take a peek at some of the ignores.

3. this rule setting will become the default anyway in the next major version of typescript-eslint.

---

If you want to take it for a spin, I took the liberty of upgrading to @typescript-eslint:v3.2.0 in a demo branch so you could quickly/easily try it out.

Note, haha, I definitely won't be offended if you're not interested in using it, don't worry! 😸

[chandlerprall]

Nice! It'd be great to enforce having comments on these (and prepping for the upcoming ts-expect-error). How does this interact with our existing "@typescript-eslint/ban-ts-ignore": "off", ?

[dimitropoulos]

ban-ts-ignore was removed in v3 and replaced with ban-ts-comment, which covers ts-nocheck and ts-check as well.

[chandlerprall]

Great! Is your demo branch ready to be PRed, or are there other considerations needed?

[dimitropoulos]

ready to be PR'd I believe - I'll make one tonight after work. This came up because I actually have a different linting change to suggest after this goes in: (basically just a fun one to disallow React.SFC and React.FC (with an autofixer for a refactor) since this project doesn't prefer them (I'll make a separate PR later)).