Open

Description
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.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
megan-starr9 commentedon Oct 12, 2017
Seconding (and wanting to track this)
This would be super helpful in our case as we have a class with a bunch of variables, and a function that accesses them by key value (vs direct getter function). As a result, they are never called directly within the class and are throwing the error despite being necessary to the functionality. I don't want to have to disable the "noUnusedLocals" check across the board, just in the two classes where this is the case.
Edit -
It's been 2 years and a job change, but I wanted to clarify something bc I'm looking back at old issues and realized this description is slightly unhelpful
My use case for this request was more along the lines of this introduced feature
#33383
But I imagine I did not want to ignore every rule in the file, so wanted to be able to specifically turn off the rule that wasn't preventing working code in an edge case, but we didn't want becoming common practice through the code base
Ristaaf commentedon Nov 28, 2017
I would also love this, more specifically for the noUnusedLocals rule, we get errors on this:
Saying that BinaryExpression is not used, but it might be, depeding on the value of this.expression.type. I could make BinaryExpresison public, but I really think it is a private method.
alexburner commentedon Dec 13, 2017
This would also be very useful for our team, we are slowly migrating a large JS app to TS. We'd like to turn on strict compilation flags (especially
--noImplicitAny
and--strictNullChecks
) but have lots of deviant files that need fixing.Specific error suppression would allow us to gradually migrate everything to strict compilation.
stweedie commentedon Jan 24, 2018
It's actually absurd that this is even still an issue. I've experienced a problem related to this. The underlying cause was due to a typescript change in 2.4, as discussed here:
ag-grid/ag-grid#1708
We were then left with three options
option 1 is not preferable, as it means we can't leverage any new typescript features and can result in having mismatched dependencies
options 2 and 3 are possible (although difficult), and they really only handle one such specific 'error' preventing successful compilation.
Why is there not an option for us to 'ignore' TS2559 (as an example)?
Busyrev commentedon Feb 15, 2018
@stweedie I made pull request with ability to specify error code to ignore, #21602 but nothing happens,
@Andy-MS What you think about?
thw0rted commentedon Apr 25, 2018
@Ristaaf I know it's been a while, but I think your use case (
private
but only referenced dynamically) could use the@internal
decorator, like/** @internal */ BinaryExpression() { ... }
. Technically your method ispublic
sotsc
won't complain but it doesn't show up in the docs as being part of your API. (I can't seem to find any docs on@internal
but I know it's used extensively in Angular...)175 remaining items