Existing rule that is somewhat related to this request - switch-exhaustiveness-check

For switches it's definitely easy to parse, understand, and report against.
Switches are unambiguous in their subject and the cases that are checked - so it's easy to see.

When paired with switch-exhaustiveness-check it would allow you to easily ensure all switches are always guaranteed to be exhaustive!

However ifs are a lot more tricky.
Solving for if's is a "hard problem"™ to solve because they support arbitrary logic that can be in weird combinations and orderings, and can be interleaved with other checks.

For example

type MyUnion = 'a' | 'b' | 'c';

declare const myUnion: MyUnion;
if (myUnion === 'a' || myUnion === 'b') {
  // ...
} else {
  // ...
}

if (myUnion !== 'b' && myUnion !== 'c') {
  // ...
} else {
  // ...
}

if (myUnion === 'a' && otherCondition === 'someValue') {
  // ...
} else if ((myUnion === 'b' || myUnion === 'c') && otherCondition === 'other') {
  // ...
}

TS seems to understand the control flow and narrow the type, so I was hoping we could benefit from this information in a lint rule—rather than trying to infer it for ourselves.

type MyUnion = 'a' | 'b' | 'c';

declare const myUnion: MyUnion;
if (myUnion === 'a' || myUnion === 'b') {
  // ...
} else {
  myUnion; // TS knows this is `'c'`
}

if (myUnion !== 'b' && myUnion !== 'c') {
  // ...
} else {
    myUnion; // TS knows this is `'b' | 'c'`
}

declare const otherCondition: 'someValue' | 'other' | 'foo'

if (myUnion === 'a' && otherCondition === 'someValue') {
  // ...
} else if ((myUnion === 'b' || myUnion === 'c') && otherCondition === 'other') {
    myUnion; // TS knows this is `'b' | 'c'`
}

Is that possible?

Ah I think I see what you're saying now, my bad!

yeah the problem isn't know what type the thing is - we can definitely do that whenever we've got the identifier in the code.

The problems are:

(1) an if can have multiple things as its subject - so it's really difficult for static analysis to handle this.
Eg the last case I listed - what if otherCondition is also a union type? Would it complain about both?

(2) I don't believe that there's an easy way for us to speculatively ask TS things at certain points in the code. Eg "hey TS, we have an else block - tell us type of this identifier within this block based on the control-flow".

(3) Because ifs are so flexible, it's really hard to understand developer intent or provide strong lint guidance.

For example:

declare const myUnion: 'a' | 'b' | 'c';
if (myUnion === 'a') {
 // ..
} else {
 // ..
}

Is this a bad if? Should it instead be listing else if (myUnion === 'b' || myUnion === 'c')?
What about if there are n members of the union, and only 1/2 of them are checked?
What do you do if there are negative matchers?

The logic and number of cases sort of explodes every quickly for ifs.

But switch/cases are very simple in structure and are thus easy to deal with :)

That makes sense, thanks for explaining.

I guess for switches it could be as simple as banning default, in combination with switch-exhaustiveness-check?

I'd be happy to see an option in switch-exhaustiveness-check which bans default

Similarly, I'd like an option to simultaneously allow default AND require all cases on a switch.

const HandledErrorCodes = [1,2,3]
type HandledErrorCodesType = typeof HandledErrorCodes[number] // 1 | 2 | 3
...
async foo() {
  try {
    await ApiCall()
  } catch (err) { 
    if (!HandledErrorCodes.includes(err)) { Sentry.captureException(err) } // report unknown errors
    this.setState({ err })
  }
}

render() {
  switch (this.state.err) { 
    case 1: return 'Error 1'
    case 2: return 'Error 2'
    // case 3 missing. linter warning wanted
    default: return 'whoops' // i do want a default as a catchall, for unknown errors
  }
}

@k-funk Isn't that https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/switch-exhaustiveness-check.md?

@k-funk Isn't that https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/switch-exhaustiveness-check.md?

It doesn't appear so. The difference is that I am looking for exhaustive AND an optional default. That rule seems to turn off exhaustiveness once default is used.

So to summarize. Here are the things being proposed here. For a non-exhaustive switch that...

declare const literal: "a" | "b";

switch (literal) {
  case "a": break;
  default: break;
}

declare const literal: "a" | "b";

switch (literal) {
  case "a": break;
}

declare const literal: "a" | "b";

switch (literal) {
  case "a": break;
  case "b": break;
  default: break;
}

declare const literal: "a" | "b";

switch (literal) {
  case "a": break;
  case "b": break;
}

declare const infinite: string;

switch (infinite) {
  case "a": break;
  case "b": break;
  default: break;
}

declare const infinite: string;

switch (literal) {
  case "a": break;
  case "b": break;
}

*Note: switches against infinite types are always non-exhaustive by definition.

Is this correct?

switch-exhaustiveness-check + ignoreDefault is what i would like to see

@JoshuaKGoldberg there is still a bug here:

    '@typescript-eslint/switch-exhaustiveness-check': [
      'error',
      {
        allowDefaultCaseForExhaustiveSwitch: false,
        requireDefaultForNonUnion: true
      }
    ],

    const getRandomString = (): string => 'asdf';

    const x = getRandomString();
    switch (x) {
      case 'aszdfasdf':
        break;
      default:
      ^^^^^^^
        break;
        ^^^^^
    }

The switch statement is exhaustive, so the default case is unnecessary.eslint[@typescript-eslint/switch-exhaustiveness-check](https://typescript-eslint.io/rules/switch-exhaustiveness-check)

The switch statement is not exhaustive.

This needs to reopen

Duplicate of #8165. This issue is for implementing a feature; bugs related to the feature are separate issues.