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:
        // ...
}

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.

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

The difficulty with building this out will be the interaction between both types and control-flow analysis.
This is definitely going to be a REALLY complicated rule for someone to build and you'll need to dig into some pretty gnarly parts of TS's APIs to get this working properly.

TS does have noFallthroughCasesInSwitch, though I don't know how it compares to the lint rule.

I don't think fixing this by changing typescript-eslint to allow the missing break statements is a good idea. This just introduces a footgun for code without 100% accurate typing, incorrect/missing data validation etc because we have no way of knowing for sure if the switch case statements will actually be exhaustive at runtime.

The safer and imo better fix here would be for Typescripts compile time error to allow for break statements in supposedly unreachable code somehow.

The safer and imo better fix here would be for Typescripts compile time error to allow for break statements in supposedly unreachable code somehow.

Honestly not a crazy use of a TS error suppression

switch (foo) {
  case bar: 
    neverReturningFunction()
    // @ts-expect-error -- ensure this branch is syntactically guaranteed to terminate
    break;
}