Don't require an exemption for an exemption

[monfera]

Currently, one can't just write

// @ts-ignore
[some code not handled well by TS]

it has to be the super noisy

// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore
[some code not handled well by TS]

Let's deactivate it by deactivating the ban-ts-comment, unless we have a reason not to. One can already grep for @ts-ignore instances

[monfera]

Btw. I'm also interested if it's not a good idea; maybe it's possible to replace all // @ts-ignore cases with something like as unknown as MyType, which is clearer

[markov00]

My personal preference is to avoid whenever possible the use of // @ts-ignore
The issue is not about how well TS interpret something, but how much we want to force TS to accept code that is wrongly typed and/or used.
The case I see are related to few extra precaution checks (we can't 100% rely on the fact that the user library use TS so we have few extra checks on values on some test) or few wrong type assignments (I've just spotted a possible bug caused by this).
What is your use case to use ts-ignore?
also remember that the eslint rule is set to warning so it doesn't prevent you from compiling and committing, it just notify the IDE about that. I think you can safely ignore that warning and live with that underlined comment without the need to disable the next line eslint rule

[monfera]

tl;dr This is fine with me, and found an alternative, closing this issue.

===========

Background:

There are hundreds of open issues in the TS repo for things that could be typed or even inferred, but not yet supported, so just because TS doesn't cover something doesn't mean it's wrongly typed or used. I'd feel uncomfortable about switching to a 5x slower code version just because sometimes they're easier for TS (see thread in the typescript channel) and need no as, or fewer as. And even such a switch doesn't always help. Interested in how all our team members handle such tradeoffs.

The current case: symbols, which are otherwise as standard keys for objects as strings are, are not fully handled by TS (TS2538: Type 'symbol' cannot be used as an index type.):

• a 6 year old open issue (see my comparison on the bottom)
• a 2yro, active, open PR

I ended up not needing the @ts-ignore, because the fast code version "only" required a few as. Which also bypasses TS type checks there, but in a more specific way. Not sure how much difference there is between // @ts-ignore and as, or as unknown as in the case of a single-line assignment, and one needs an eslint-disable-next-line and the other doesn't.

[monfera]

Hmm not sure I can handle all cases; eg. with symbols, I'd need to lie to TS eg. fields[k as string] when I know k can be a string or symbol. It feels better to ignore TS for a line than to lie to TS and my peers 😄 I'd also seem wrong to replace symbols with strings just because TS has a blind spot there. Good topic for a chat

[nickofthyme]

Yeah, I think trying to make it work in typescript is the best case and // @ts-ignore is a last option.