Repository navigation
Object with all context-sensitive properties requires at least one non-context-sensitive property for inference to workย #64251
Description
๐ Search Terms
object with all context-sensitive properties, self referencial types, xstate
๐ Version & Regression Information
Tested with TypeScript 7.0.2, the issue exists even in versions as old as 4.4.4
โฏ Playground Link
๐ป Code
// problem: doesn't infer D correctly, context and state are any
createMachine({
initial: "a",
context: { foo: 1 },
states: {
a: {
entry: (context, state) => {
context
// ^? any
state
// ^? any
}
}
}
})
// solution: add a useless non-context-sensitive property `_: null`
createMachine({
initial: "a",
context: { foo: 1 },
states: {
a: {
entry: (context, state) => {
context
// ^? { foo: number }
state
// ^? "a"
},
_: null
}
}
})
declare const createMachine:
<D extends {
initial: keyof D["states"],
context: object,
states: {
[S in keyof D["states"]]: {
entry?: (context: D["context"], state: S) => void,
_?: null
}
}
}>
(definition: IdentityObject<D>) =>
D
type Identity<T> =
T extends any
? ( T extends (...a: never) => unknown ? T :
T extends object ? IdentityObject<T> :
T
)
: never
type IdentityObject<T> =
{ [K in keyof T]: Identity<T[K]> }๐ Actual behavior
The first createMachine invocation doesn't infer the type parameter correctly (it requires at least one non-context-sensitive property) and hence context and state parameters of entry are not inferred.
๐ Expected behavior
The first createMachine invocation should infer the type parameter correctly without having to pass in a non-context-sensitive property leading to inference of context and state parameters of entry
Additional information about the issue
The premise is adding (or rather not adding) an extra useless property shouldn't make a difference to the inference
Activity
RyanCavanaugh commentedon Sep 14, 2026
Mateusz Burzyลski (@Andarist) any thoughts (on this or the PR) ?
RyanCavanaugh commentedon Sep 14, 2026
Copilot cites #48798 as prior work in this area, with #54029 as a superset of the linked PR
Andarist commentedon Sep 16, 2026
#54029 would resolve this issue already here - so it's kinda strong duplicate of #48798 . That said... #54029 doesn't resolve all cases and I'm cooking up a revised PR of that for TS Go. Stay tuned ๐
devanshj commentedon Sep 17, 2026
Mateusz Burzyลski (@Andarist) Nice... A bit of a trivia / fyi given you took this problem out of txstate (linking for others), this whole
Identity(orInferNarrowest) is actually a workaround... so even if this reverse mapped type issue is resolved, it's still not enough to type abstractions like xstate, for that we need #64091, eg I'd be curious if you can type this with your PR... But then again any progress is good!