satisfies operator fails to recognize optional properties that are defined

[UselessMnemonic]

Bug Report

🔎 Search Terms

"partial" "satisfies" "narrow"

🕗 Version & Regression Information

Tried on version 5.1.5

⏯ Playground Link

https://www.typescriptlang.org/play?exactOptionalPropertyTypes=true#code/C4TwDgpgBAqgzhATlAvFA3gWAFBT1RCAQwBMB7AOwBsQoBLEgLijmETooHMAaHfA4uWq04ZALYQAggGNgdSswAUASlQA+KADcyDHAF8cOUJCgBZAK7AiAIyoQAPABUNaLLnwBaQqUo0oAbQBpegooAGsIEDIAMyhHAF1mRyD4-UNsaPMKWXlQ6W9gCHgkRQZmVnYuZWZi5Dd+aUpWKAoIAHda5gsrWwcABSJEOSIqe1q1Fwx6Eig9AG50-laOhEQAOlEJGTlKVCgVdSmAegAqKDWLqBOj2YXsPnxCYHNEUOXaliI5OGi6CDhYKs5ngjjdokQ6FQ4GlsEA

💻 Code

type User = {
    readonly id: string,
    readonly someAction: () => void
}

type UnfinishedUser = {
    id: string,
    someAction?: () => void
}

function createUser(id: string): User {
    const newUser: UnfinishedUser = { id };

    newUser.someAction = () => { /* ... */ };

    return newUser satisfies User;  // fails
}

🙁 Actual behavior

newUser does not satisfy User

🙂 Expected behavior

newUser should satisfy User

[jcalz]

As far as I know, existingVariable satisfies Type has essentially no effect, so it's not surprising that satisfies isn't doing anything here. I'd say satisfies is a red herring and the underlying issue is that assigning the someAction property of newUser doesn't narrow newUser itself, and as such this is a duplicate of #42384. If that were to be implemented then your code would start working (but you still wouldn't need satisfies). For example:

// simulate #42384
function addProp<T extends object, K extends PropertyKey, V>(
    obj: T, k: K, v: V): asserts obj is T & Record<K, V> {
    Object.assign(obj, { [k]: v });
}

function createUser(id: string): User {
    const newUser: UnfinishedUser = { id };
    addProp(newUser, "someAction", () => { /* ... */ });
    return newUser satisfies User;  // okay
}

function createUser2(id: string): User {
    const newUser: UnfinishedUser = { id };
    addProp(newUser, "someAction", () => { /* ... */ });
    return newUser;  // still okay
}

Playground link

[UselessMnemonic]

I understand, I think what I'm looking for is more explicit type guards. Using as in the return statement, although subtle, better conveys the behavior I desire:

type User = {
    readonly id: string,
    readonly someAction: () => void
}

type UnfinishedUser = {
    id: string,
    someAction?: () => void
}

function createUser(id: string): User {
    const newUser: UnfinishedUser = { id };

    newUser.someAction = () => { /* ... */ };

    return newUser satisfies User as User;  // fails
}

My goal is to ensure newUser does in fact satisfy User without satisfies having a side-effect on the type itself (as if to cast, like my initial suggestion implies.) Clearly as will succeed anyways, but not without loosing some type safety. The two operators could work well in tandem, if only satisfies was smarter.

[typescript-bot]

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