Type narrowing inconsistency with different union type definitions

[k8w]

🔎 Search Terms

type narrowing, union type, conditional type, discriminated union, type inference

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about type narrowing and discriminated unions.

⏯ Playground Link

No response

💻 Code

// Worked!
function test1(value: { type: 'a' } | { type: 'b' }) {
    if (value.type === 'a' || value.type === 'b') { }
    else {
        // @ts-expect-error
        throw new Error(`asdf ${value.type}`)
    }
}

// Not Worked!
function test2(value: { type: 'a' | 'b' }) {
    if (value.type === 'a' || value.type === 'b') { }
    else {
        // @ts-expect-error
        throw new Error(`asdf ${value.type}`)
    }
}

### 🙁 Actual behavior

In test2, TypeScript fails to narrow the type of value within the if statement, even though the condition explicitly checks against all possible values of value.type. The else block, therefore, does not produce a type error, despite logically being unreachable. The @ts-expect-error directive is ignored. This is inconsistent with the behavior in test1, where the equivalent logic does correctly narrow the type. The only difference is the way the union type is defined: { type: 'a' } | { type: 'b' } versus { type: 'a' | 'b' }.

### 🙂 Expected behavior

TypeScript should consistently narrow the type in both test1 and test2. The else block in test2 should produce a type error, just as it does in test1, because the condition ensures that the else block is logically unreachable. The @ts-expect-error directive should correctly reflect this. The type narrowing behavior should not depend on the syntactic form of the union type definition.

### Additional information about the issue

This inconsistency leads to unpredictable behavior and reduces the reliability of TypeScript's type safety features. A consistent and predictable type narrowing mechanism is crucial for writing robust and maintainable code.

[MartinJohns]

Duplicate of #31404.

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.