GeezerVison

Need to revert submodule updates, otherwise LGTM

This flag quite literally just suppresses the error since we already "do the right thing" in the presence of the error with respect to types. Should we not just concede to community demand and add a generalized "suppressions": ["TS2686"]-type compiler option? Because that's all this new command is an alias for. (And I imagine if we do the more generalized option we can be smart and still return the errors as suggestions, which we do not (yet?) do here)

Wesley Wigham (@weswigham) good point. I'm sure I'm missing some prior discussion here, but aren't there some error codes that are virtually unsuppressible, or would have horrifying consequences if suppressed? This particular error is a great example of something that would work, but I'm thinking about e.g. parser errors... suppressing a diagnostic from parseExpectedToken would essentially allow people to invent their own more concise non-standard syntax; in other cases, invalid syntax could parse as a totally different syntax tree than a user is expecting, without surfacing any diagnostics.

I guess a better summary of what I'm asking is—while I don't personally feel the need to try to force users into writing better TypeScript against their will, would a feature like that, on average, actually result in a better user experience? Or would it inadvertently wreak more havoc than solve problems?

As a newbie, this is a legitimate question, not rhetorical, and I'd happily defer to the team's consensus.

or would have horrifying consequences if suppressed?

We already have // @ts-ignore comments that let you suppress anything, sooooooo

We already have // ts-ignore comments that let you suppress anything

IIRC that's not the case. It doesn't suppress parse errors and declaration emit diagnostics (don't know about binder diagnostics)

It doesn't suppress parse errors and declaration emit diagnostics (don't know about binder diagnostics)

We can exclude those from the errors we'll suppress, too, then. I'm just thinking that adding a suppressions argument that acts like a ts-ignore for all errors of a specific type is probably more general, and I know I've seen requests for it (much as I personally loathe the idea of suppressing any of our errors).