Conditional types fail to distribute in properties of mapped types

TypeScript Version: 3.7.0-dev.20190928

Search Terms: conditional mapped property union

Code

type NullifyStrings<T> = T extends string ? null : T
type NullifyStringsInPropsWorking<T> = { [K in keyof T]: NullifyStrings<T[K]> }
type NullifyStringsInPropsBroken<T> = { [K in keyof T]: T[K] extends string ? null : T[K] }

type TestType = { a: number | string }
// { a: number | null }
type WorkingReplaceProps = NullifyStringsInPropsWorking<TestType>
// { a: string | number }
type BrokenReplaceProps = NullifyStringsInPropsBroken<TestType>

Expected behavior: NullifyStringsInPropsWorking and NullifyStringsInPropsBroken should be functionally identical - expanding the NullifyStrings type alias in NullifyStringsInPropsWorking results in the same definition as NullifyStringsInPropsBroken.

Actual behavior: NullifyStringsInPropsWorking and NullifyStringsInPropsBroken have different behaviour - BrokenReplaceProps has type { a: string | number } instead of the expected { a: number | null }.

Playground Link: Link

Related Issues:

#28339, but seems to be different.

#22945 mentions

Since type aliases are equivalent to writing the expansion inline […]

but that is not the case here.

[mcpower]

Did you see this section of the handbook: distributive-conditional-types?

I don’t mean this in a snide way — lots of people have been tripped up on this and if they are reading the handbook and still getting confused then I think that is good to know.

I didn’t, actually! After reading that section of the handbook, I think I still wouldn’t have understood it - the section focuses on some nice working examples and doesn’t show any examples for when things go wrong. IMO these things would be nice to have in the handbook for better understanding:

• examples of naked and non-naked type parameters - “naked type parameter” is not explicitly defined anywhere, even though the definition seems obvious
• mentioning the main counter-intuitive “gotcha” - that inlining a distributive conditional type alias may result in different behaviour
• some examples of when conditional types are expected to be distributive, but actually aren’t (the example above, #22945, #23046, #32274) - and how to work around it by using an additional type alias or extends infer.
  • The other misunderstanding, when conditional types are not expected to be distributive, but actually are (#23022), seems to be rarer. I think you previously mentioned that the workaround to avoid distribution should be in the handbook, so perhaps it’s worth mentioning.

[jack-williams]

Duplicate of #23022, #23046, and #32274.

Regarding:

Since type aliases are equivalent to writing the expansion inline […]

the subtext is that this only applies when inlining a type alias instantiated with a type parameter.

Did you see this section of the handbook: distributive-conditional-types?

I don’t mean this in a snide way — lots of people have been tripped up on this and if they are reading the handbook and still getting confused then I think that is good to know.