Support // @ts-nocheck for lint like checks like --noUnusedLocals

[egamma]

TypeScript has compiler options for several lint style checks like noUnusedLocals. For such checks it can be desirable to turn them of for a specifc location in the code. Now that there is support for // @ts-nocheck comments, this comment should also be support for the lint style options TS supports.

[mhegazy]

From the compiler perspective there is no difference between the errors that the --noUnusedLocals enable and any other errors.

We have talked about disabling errors multiple times and never reached a conclusion to add such support. we believe that all TS errors are warnings by definition (do not block emit), and that disabling some would leave your program in an inconsistent state and would negatively impact the whole experience. Moreover we believe that there are already in place language constructs that enable fixing the errors instead of silencing them.

That said, I know that features like --noUnusedLocals, --noUnusedParameters, --noImplicitFallThrough, and noImplicitReturn are rather style checks and not just type checks. but they are opt-in, and users can just switch them off all together and maybe rely on a linter rule (which tslint has removed, but i would argue can put back). and in the case of --noUnusedParameters an _ prefix disables the checking all together.

One alternative here is for these style options (--noUnusedLocals, --noUnusedParameters, --noImplicitFallThrough, and noImplicitReturn), their value could be true | false | "warn" to control the error severity.

Similar discussion can be found at #9448

[ghost]

There's currently no way to fix fallthrough though; maybe we should recognize a // falls through comment like tslint does.

[evmar]

@alexeagle has strong opinions in this area.

[alexeagle]

At Google, we've spent a lot of time working through how we present the "severity" of findings from compilers and linters. We have a paper hopefully publishing soon in CACM (I can forward a copy if you're interested).

Basically, we found that developers ignore existing warnings in the code, then that warning blindness extends to new warnings. To combat this, we only present newly introduced warnings. Compilers don't know what has changed, because it would be a layering violation for them to read info from the VCS. Therefore we found that compilers should never produce "warnings" - more precisely, if the compiler "accepts" the program, it should not produce any additional output asking developers to take some optional action.

We turned off all warnings from all compilers (I worked on the Java one quite a bit) and re-implemented the ones we care about as errors, or else left them for a linter. We're doing the same for TypeScript now.

A linter is different - you can hook it up later in the developer workflow, where you do have context from the VCS, and can show only the newly introduced things.

So I believe TypeScript should avoid non-fatal diagnostics (and unused variable was a mistake).

I would love to discuss it further!

[mhegazy]

(I can forward a copy if you're interested).

please do.

[alexeagle]

I mailed a copy to Mohamed - sorry I can't post publicly yet since it's pending publication.

…

On Wed, May 24, 2017 at 2:51 PM Mohamed Hegazy ***@***.***> wrote: (I can forward a copy if you're interested). please do. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15953 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC5I7hmGggEd7NE4Zv0plWw8s7WtB81ks5r9KZWgaJpZM4NgmtR> .

[danielweck]

+1

[mhegazy]

closed in favor of #13408. please see #13408 (comment) for the current action plan.