-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Open
Labels
Help WantedYou can do thisYou can do thisPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some casesThe current behavior isn't wrong, but it's possible to see that it might be better in some casesUnion Order DependenceTS behavior is not supposed to depend on union order, but sometimes doesTS behavior is not supposed to depend on union order, but sometimes does
Milestone
Description
🔎 Search Terms
union order type infer
🕗 Version & Regression Information
This is the behavior in every version I tried, and I reviewed the FAQ for entries about union
/ order
⏯ Playground Link
💻 Code
type Message = { options?: Record<string, unknown> };
type Handler<T> = (message: T) => void;
declare function subscribe<T extends Message>(
payload:
| { message: T } & { handler: Handler<T> }
| { message: () => T } & { handler: Handler<T> }
): void;
subscribe({
message: () => ({ options: { market: 'market' } }),
handler: ({ options }) => {
// ^? Record<string, unknown>
},
});
🙁 Actual behavior
options
type is Record<string, unknown>
🙂 Expected behavior
options
type should be inferred as { market: string }
Additional information about the issue
if you reverse the order of values in the union:
declare function subscribe<T extends Message>(
payload:
| { message: () => T } & { handler: Handler<T> }
| { message: T } & { handler: Handler<T> }
): void;
then the type will be inferred correctly
Metadata
Metadata
Assignees
Labels
Help WantedYou can do thisYou can do thisPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some casesThe current behavior isn't wrong, but it's possible to see that it might be better in some casesUnion Order DependenceTS behavior is not supposed to depend on union order, but sometimes doesTS behavior is not supposed to depend on union order, but sometimes does