Repository navigation
Variable loses type narrowing when passed as object literal #57013
Description
🔎 Search Terms
object literal type inference
enum type narrowing
🕗 Version & Regression Information
- This changed between versions 5.0.4 and 5.1.6
⏯ Playground Link
💻 Code
enum Events {
EVENT1 = 'Event 1',
EVENT2 = 'Event 2',
}
interface GenericEvent {
eventName: Events;
properties?: never;
}
interface Event1Event {
eventName: Events.EVENT1;
properties: {
data: string
};
}
interface Event2Event {
eventName: Events.EVENT2;
properties: {
data: string
};
}
type EventTypes =
| GenericEvent
| Event1Event
| Event2Event
const num = Math.floor(Math.random() * 10) + 1;
const eventName = num > 5 ? Events.EVENT1 : Events.EVENT2;
// This version fails on properties: Type '{ data: string; }' is not assignable to type 'undefined'
processEvent({
eventName,
properties: {
data: "My Event Data"
}
});
// This version works
const data = {
eventName,
properties: {
data: "My Event Data"
}
};
processEvent(data);
function processEvent(event: EventTypes) {
console.log(event);
}🙁 Actual behavior
The event passed to processEvent behaves differently if assigned to a const prior to being passed in.
🙂 Expected behavior
Both should be the same result. It's also worth noting that in the repro provided assignment to a const data = ... works to resolve the problem. But in my code this doesn't end up working and instead I need to explicitly state that eventName can only be one of the two Events values in the ternary.
Additional information about the issue
No response
Activity
RyanCavanaugh commentedon Jan 11, 2024
Which result is correct?
jasonaden commentedon Jan 11, 2024
Both the working version and the currently failing version above should work. They both worked prior to
5.1.6(didn't get into patches leading up to5.1.6so may have been introduced at first release of5.1).RyanCavanaugh commentedon Jan 23, 2024
Bisects to #53709
ahejlsberg commentedon Mar 6, 2024
The repro here is an example of the pattern covered by #30779, i.e. relating a source object type to a discriminated union of target object types where no single target type covers the possible set of source values, but the full union of target types do. We have limited support for this pattern, and we handle it by decomposing the source type into a union as long as that union doesn't have more than 25 constituents. For example, in
we decompose the object literal into a union of the two possible values
{ kind: "a", data: "hello" } | { kind: "b", data: "hello" }in order to successfully relate it toA | B.However, we attempt no such decomposition when checking excess properties in object literals. Consider
Above, when checking the object literal for excess properties, we first discriminate the target type
X | A | Bby thekindproperty specified in the object literal. It has type"a" | "b", for which we find that onlyXmatches. We then error because thedataproperty is a string that isn't assignable toundefined. Since we only do excess property checking for object literals, there's no error when we first assign the object literal to a variable (but the assignment only succeeds because of #30779).Considering the rarity of this problem and the complexity of incorporating the decomposition pattern into excess property checking, I'm going to call this a design limitation.
typescript-bot commentedon Mar 9, 2024
This issue has been marked as "Design Limitation" and has seen no recent activity. It has been automatically closed for house-keeping purposes.