Satisfies operator doesnt carry over optional properties

[alesmenzel]

Bug Report

🔎 Search Terms

satisfies, optional property

🕗 Version & Regression Information

• This is a crash - No
• This changed between versions - Since introduction of satisfies
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about satisfies operator
• I was unable to test this on prior versions because satisfies operator was introduced in 4.9

⏯ Playground Link

Playground link with relevant code

💻 Code

type ListItem = {
    id: string
    label: string
    disabled?: boolean
}

const listA = [{
    id: 'foo',
    label: 'Foo',
    // disabled: true
}] as const satisfies readonly ListItem[]

// "Property 'disabled' does not exist on type"
// Should not error here, since the listA should satisfy ListItem type which has disabled property
// EXPECTED: listA[0].disabled has type boolean | undefined
listA[0].disabled
//          ^?

const listB = [{
    id: 'foo',
    label: 'Foo',
    disabled: true
}] as const satisfies readonly ListItem[]

// Here the type is correctly resolved to `true`
listB[0].disabled
//          ^?

🙁 Actual behavior

Readonly literal types that satisfy a type don't carry over optional properties that might not be set. Setting the type directly would mean we lose the literal types.

🙂 Expected behavior

Optional properties are carried over when a const satisfies some type. Expected type of listA is { id: 'foo', label: 'Foo', disabled?: boolean }[]

[alesmenzel]

Workaround is to set the values as undefined explicitly.

const listA = [{
    id: 'foo',
    label: 'Foo',
    disabled: undefined
}] as const satisfies readonly ListItem[]

listA[0].disabled // undefined

[RyanCavanaugh]

This is the intended behavior of the satisfies operator. See discussion at #47920

[fatcerberus]

Huh, I recall that the primary debate over satisfies was basically between “type-check only” vs. “safe upcast” (with the former winning out); it never even struck me there was this third possibility of “infer ExpressionType & CheckType”; that’d have been kind of clever, actually.

To OP: Note that explicitly setting to undefined won’t work anymore if you ever decide to turn on exactOptionalPropertyTypes.

[alesmenzel]

It would be nice to have some way to define that a constant variable conforms to some type and would carry over the type. @RyanCavanaugh Maybe could be a new feature request? or what are your thoughts on this topic?

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.