Support @ts-ignore for specific errors

TypeScript Version: 2.6.0-dev.20171011

Code

function countDown(n: number): void {
    switch (n) {
        // @ts-ignore
        case 1:
            console.log("1");
            // intentional fall through
        case 0:
            console.log("0");
    }
}

Expected behavior:

Ability to make ts-ignore apply to the --noFallthroughCasesInSwitch error but not to other errors.

Actual behavior:

case "1": would also compile.

[sarimarton]

I’m repeatedly coming back to this issue. @ts-expect-error doesn’t make sense without specifying the error. I don’t mind that @ts-ignore can’t be narrowed down, eslint’s default rules prohibit @ts-ignore anyway. The problem with @ts-ignore is the implicit cleanup condition. But @ts-expect-error makes a lot of sense a lot of times with narrowing it down to one specific error. Eslint expects me to add a comment as well. But expecting any error makes the flag unsafe. So what’s the point then?

Having said this, all the places where I see a reaction from a TS representative, I see wrong arguing. Focusing on @ts-ignore, bringing in short names (why?)…

“We don’t want people to get into a situation where upgrading from TS X.Y to X.Y+1 yields hundreds of new errors simply because we changed an error message code”

I see 3 problems with this (at least):

1. It’s arguing with extremes. Having hundreds of @ts-expect-error on one particular error type in a codebase feels like a fishy case, but quite uncommon at least. And even then, I don’t see a problem with search-and-replacing those comments. Also how common is that TS changes an error code for the same error condition? Has it even ever happened?

2. Also, narrowing down @ts-expect-error is the developer’s responsibility with all the consequences.

3. It’s indeed counterintuitive that error codes are tied to the error text. Why is that? Nobody expects that errors are defined by their text. Everybody treats the text as prone to being changed over time. That’s why there’s a code. On the other hand, introducing a new code for the same error already adds inconsistency to the global TS knowledge - think about googling new error codes not matching the results for the old one; and then maintaining a code history on all the blog posts and help pages on the internet, which explains a particular error…

[arthur-clifford]

The only actual argument, if I’m not mistaken, is the instability of the error codes.

A couple thoughts

1. I really hope your team did something to standardize error codes between versions; the fact that there was any resistance to that idea is itself disturbing. It is the more forward compatible option that gives the most flexibility in the long run even if you end up with a bunch of unused codes. It may be hard, but who cares about hard; if we wanted easy we’d all be using square space and not coding our own stuff in typescript.
2. There have been very compelling arguments for the utility of refined expect-error or ts-ignore entries.
3. noIplicitAny and other tsconfig linter options are already examples of this capacity except they use names rather than codes; the advantage of the codes is that they can be linked to definitions that are internationalized.

All we are asking for is the ability to ignore those errors that we deem to be more style than error especially when the code actually runs, yet not have to not turn everything off.

The general reply in effect is that it is a bad idea to turn off errors but if you have to then turn them all off which makes no sense at all whether at the global or individual line level.

What would the actual level of effort be to implement ignorable/expectable error codes at the comment AND tsconfig level for consistency?

If it were implemented, would the folks in this thread be ok with the ts compiler generating a report of ignored errors that could in some way (via opt-in program) reported back to the ts dev team so that they can have some real world feedback on what all is getting ignored?

My problem with suggestions like “we are not seeing issues with …” is that you aren’t looking at any real code. You are waiting for the rarified people who know enough to complain, and with enough time to, to actually complain. To make those kind of arguments you need real feedback but if you are making it so we can’t know what the errors we’re ignoring are, except all of them, then how can you possibly know that your errors are useful or what the consequences of your choices are?

I’m thinking there is an opportunity for a meaningful feedback loop and a win-win if you let us codify our overrides inline with some metric info going back to you rather than have to come here to complain about things,

// @ts-ignore TS/1234 because I know what I’m doing Seems a lot more reasonable than // @ts-ignore developers Which leads to // @ts-expect-error typescript devs do not care so neither should we