Allow explicit fallthrough when noFallthroughCasesInSwitch is enabled

🔍 Search Terms

fallthrough noFallthroughCasesInSwitch

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

    switch (...) {
        case 'A':
            doSomething();
            // fallthrough - this will allow falling to next statement
        case 'B':
            doSomethingElse();
   }

Instead of usage of @ts-expect-error this is nicely readable and intention is clearly visible in generated code.

📃 Motivating Example

Until now for noFallthroughCasesInSwitch is missing good way to allow falling through if needed. The only possible way @ts-expect-error is disabling not only fallthrough check, but also other checks which is not desired.

💻 Use Cases

1. What do you want to use this for? Because eslint rule no-fallthrough does not handle TS exhaustive match, I would like to you noFallthroughCasesInSwitch config rule

2. What shortcomings exist with current approaches?

   • eslint can not be used, its no-fallthrough rule can not detect exhaustive match, so the following code is incorrectly reported by eslint:

   function transform(action: 'KEEP' | 'INVERSE', b: boolean): boolean {
       switch (action) {
           case 'KEEP':
               switch (b) {
                   case true:
                       return true;
                   case false:
                       return false;
               }
           case 'INVERSE':
               switch (b) {
                   case true:
                       return false;
                   case false:
                       return true;
               }
       }
   }
   

   • satisfying eslint is not possible e.g. by putting break, because TS will start report Unreachable code detected and this can not be disabled by @ts-expect-error
   • disabling reported case by @ts-expect-error is also not viable, because it is disabling all type checks, so e.g. in case case something: validation that something has the correct type is also disabled (and issue #19139 is still opened)

3. What workarounds are you using in the meantime? In my specific case, I had only one of these switches with exhaustive match, so I could put the statement as the last to not disable any check.

Implementation of #19139 would give me decent workaround and it is definitely more useful that this specific feature, but I believe both of them should be implemented.

El issue no menciona archivos ni tests; empieza por localizar el diagnóstico noFallthroughCasesInSwitch y las comprobaciones de control de flujo de switch en el compilador de TypeScript. Compara el marcador de fallthrough propuesto con los casos existentes de @ts-expect-error y exhaustive-match, y añade cobertura específica que muestre que el fallthrough intencional sigue sometiéndose a comprobación de tipos.