Repository navigation
Support // @ts-nocheck for lint like checks like --noUnusedLocals #15953
Description
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.
Activity
mhegazy commentedon May 19, 2017
From the compiler perspective there is no difference between the errors that the
--noUnusedLocalsenable 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, andnoImplicitReturnare 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--noUnusedParametersan_prefix disables the checking all together.One alternative here is for these style options (
--noUnusedLocals,--noUnusedParameters,--noImplicitFallThrough, andnoImplicitReturn), their value could betrue | false | "warn"to control the error severity.Similar discussion can be found at #9448
evmar commentedon May 20, 2017
Alex Eagle (@alexeagle) has strong opinions in this area.
alexeagle commentedon May 24, 2017
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 commentedon May 24, 2017
please do.
alexeagle commentedon May 24, 2017
danielweck commentedon Jul 6, 2017
+1
mhegazy commentedon Oct 9, 2017
closed in favor of #13408. please see #13408 (comment) for the current action plan.