TS not properly resolving keys of generic conditional type when used in Omit

[BlueLdr]

🔎 Search Terms

"generic conditional" "omit conditional" "keyof conditional"

🕗 Version & Regression Information

• Occurs in all versions available in TS Playground

⏯ Playground Link

https://www.typescriptlang.org/play?pretty=true&ts=5.3.3#code/C4TwDgpgBAQghgZwgHgGIBs4HMoQB7AQB2AJglAEYD2V6EcRAfFALxQDeAUFFAGY0B+AFxQEwAE4BLIlgDcnAL5QAZFAAU3KBmy4CxMlAkBXaAI6aevTFhHGI8njwpxxIsVJkBtALoOoSkS5HPmthPjh0JD8nFzcJaTlNBU4ASk5OUEgoAHlgAAsIcXgkVnNLQRFqWnoiPwQqAFsIfISwqgoAKwgAY2B5ZIzwaABZEAAFcSowBDRrXUJSciq6BmY2YpRtLGZVbIbJYGRcgqLECAAaKABrCBAqXlgz2exGRnTuqiIxXTgGsDpSs8cPgFgZljVGGorNgRFsUqxmEFDENHkgANK3chsG53B4bIGMPwAeiJhjyknIhUm4igFN0kF6EBIlwYJFp5AA7lRxFcElAwJNIOJ0CBNB8vsBKGcMSARBsZVioAAiepNFoyJWyKAkqAAUQASvrsvqRAByFWNZrkjWm9lQIhUSWIBCSLBEOAUAHAKjIrIAAyV-CoSqgAB8oAA6KN+zSZaDHQryzGlHH3HL5RNnPzi76Ok5J2Xp-PS5NsC1q61YTWxlGjBUp25p0YTKYzLaEzQ6lqU8TUu0AOWyABV6T1CCQxZ9vg0QDKRHXS8rVVaEprtaSDUaTVBzcv1VXbXSHU6EC63R6vT641AA0GQ+GoxGw3q8N10EYSChAzQlZdv8Hn0fZhw11V930-ZByxXDU-zvQCo0YGMFCAA

💻 Code

type Base<Flag extends boolean> = {
  foo?: string;
} & (
  Flag extends true ? {
    flag: true;
    bar: string[];
  } : {
    flag?: false;
    bar: string;
  }
)

type OtherBase = {
  foo?: boolean;
  something?: object;
}

type MyProps<Flag extends boolean> = Base<Flag> & Omit<OtherBase, keyof Base<Flag>>

const example = <Flag extends boolean>(flag: Flag) => {
  type BaseKeys = keyof Base<Flag>;
  // this error is expected, and is working properly
  const baseKey: BaseKeys = "something"; // ERROR: '"something"' is not assignable to type `"foo" | ...`
  type OtherBaseKeys = keyof OtherBase;
  const otherBaseKey: OtherBaseKeys = "something";
  type MyKeys = keyof MyProps<Flag>;
  // this error is NOT expected
  const myKey: MyKeys = "something"; // ERROR: '"something"' is not assignable to type `"foo" | ... | Exclude<"foo", "foo" | ...> | Exclude<"something", "foo" | ...>`
}

🙁 Actual behavior

"something" is not assignable to keyof MyProps<Flag>. It is Omitted from OtherBase even though it is never a possible key of Base, no matter what the value of the generic is or how the condition resolves.

Interestingly, "something" still appears as an autocomplete suggestion when typing a value for myKey.

🙂 Expected behavior

The resolved type of keyof MyProps<Flag> should (effectively) be "something", and thus "something" should be assignable to myKey.

Additional information about the issue

I'm trying to combine two types that have some overlap by omitting the common keys in one of them and then intersecting them. But this seems to be omitting all keys from the one type, when the other type is a generic conditional type. In the example, TS knows that "something" is not in BaseKeys, and is in OtherBaseKeys, but Omit<OtherBaseKeys, BaseKeys> is somehow omitting "something". The conditional type clearly has a known set of keys that stays the same no matter how the condition resolves. So why doesn't TS resolve the keys properly when using Omit?

I know this can be done (and works properly) with a discriminated union instead of a conditional. It originally was a DU, but I had to change it to a conditional to get some other usages working properly.

[mkantor]

Here's a simpler reproduction of what I think is the same problem:

type Conditional<T extends boolean> = T extends true ? 'a' : 'b'
const f = <T extends boolean>() => {
  const c1: Exclude<'a' | 'b' | 'c', Conditional<boolean>> = 'c' // ok
  const c2: Exclude<'a' | 'b' | 'c', Conditional<T>> = 'c' // error
}

I would have expected Conditional<T> to evaluate the conditional type using T's constraint and for the c2 assignment to be valid there.

---

EDIT: Thinking about this more deeply, I guess we wouldn't want this to be accepted (because T might be true):

type Conditional<T extends boolean> = T extends true ? 'a' : 'b'
const f = <T extends boolean>() => {
  const b: Conditional<T> = 'b'
}

Things really only get weird in the specific cases where you want to use such a type in a negative sense (e.g. as the second parameter to Exclude or Omit) where widening to the constraint seems reasonable.

[MartinJohns]

This is a known design limitation.

Resolving of conditional types with unbound generic arguments is deferred. What type does Conditional<T> resolve to? The compiler doesn't know what type T is, so it can't resolve the conditional type.

[mkantor]

@MartinJohns yeah, that makes sense (and I came to the same conclusion myself before seeing your comment). Now I'm wondering if there would be some way to make such problems more obvious, like getting the type info for a type like Exclude<'a' | 'b' | 'c', Conditional<T>> to display as never or similar (I think that's what it conceptually is?).

[MartinJohns]

Exclude<'a' | 'b' | 'c', Conditional<T>> to display as never

But it's not never.

[BlueLdr]

This is a known design limitation.

Resolving of conditional types with unbound generic arguments is deferred. What type does Conditional<T> resolve to? The compiler doesn't know what type T is, so it can't resolve the conditional type.

I had a feeling that was gonna be the case. I would still think that we could make an exception for the keys, specifically when both branches of the conditional have the same set of keys. In other words, we can be certain that the resolved type of Base<Flag> will always be some object with possible keys foo, bar, and flag, regardless of what Flag is or what the property value types are for those keys.

Am I missing something there? If we did this, what other cases would break?