[no-fallthrough] Lint rule needs type information to avoid false positives e.g. nested switch

[OliverJAsh]

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have read the FAQ and my problem is not listed.

Repro

{
  "rules": {
    "no-fallthrough": [2]
  }
}

declare const n: { a: 1; b: 1 | 2 } | { a: 2 };
(() => {
  switch (n.a) {
    case 1: {
      switch (n.b) {
        case 1:
          return 1;
        case 2:
          return 1;
      }
    }
    // ESLint error:
    // Expected a 'break' statement before 'case'.
    case 2: {
      return 2;
    }
  }
})();

Expected Result

No lint error

Actual Result

Lint error (see comment)

Additional Info

I think the TS ESLint plugin needs to provide its own version of no-fallthrough in order to take advantage of type information so we can avoid false positives such as this.

Versions

package	version
@typescript-eslint/eslint-plugin	latest
@typescript-eslint/parser	latest
TypeScript	latest
ESLint	latest
node	latest

[BobNobrain]

Another example of code with false positive no-fallthrough error due to lack of information about types:

switch(x) {
    case 0:
        process.exit(0);
        // putting `break` here silents no-fallthrough, but causes unreachable code warning from ts

    default:
        // ...
}

[wclr]

Wanted to make new rule proposal but then found this. So core no-fallthrough requires an unneeded break, even if a nested switch case is exhaustive. But exhaustiveness of the case can be detected only with types.

Such code with core `no-fallthrough enabled requires unneeded break:

const fn = (x: "A" | "B", n: "Err" | "Ok"): number => {
  switch (x) {
    case "A":
      switch (n) {
        case "Ok":
          return 1
        
        case "Err":
          return 0  
        
      }
    break; // this break actually not needed with typescript 
    default:
      return -1
  }
}

TS config actually has the option noFallthroughCasesInSwitch, which almost checks the same thing, but error reporting is a bit scarce.

[dani-mp]

Had this problem today with a nested switch. The formatter removes the unnecessary breaks. And eslint complains about them being expected.