TypeScript allows unsafe Partial usage in generic

Question

Issue

I'd like to do CRUD stuff on some unknown items (any object with id: number).

For simplicity, let's say that for now we're deling with messages like this:

type Message =
    | { id: number; type: "success"; message: string }
    | { id: number; type: "error"; message: string; status: number };

let messages: Message[] = [{ id: 1, type: "success", message: "Ok" }];

Please notice that if type === "error, status has to be provided (can't be undeifned, since hanlder could use .toPrecision() or other number method).

Update function can look like this (just a basic demo):

function updateItem<T extends { id: number }>(
    items: T[],
    id: number,
    changes: Partial<T>
): T[] {
    return items.map((item) => {
        if (item.id === id) {
            return { ...item, ...changes };
        }

        return item;
    });
}

Let's test it:

messages = updateItem(messages, 1, { type: "error" });
console.log(messages);
// => [{ id: 1, type: "error", message: "Ok" }]

and just like that TypeScript allowed me to create invalid message. It has type === "error", but it doesn't have a status.

It would notify about if I would implement it like this:

function updateMessage(
    items: Message[],
    id: number,
    changes: Partial<Message>
): Message[] {
    return items.map((item) => {
        if (item.id === id) {
            return { ...item, ...changes }; // TS ERROR
        }

        return item;
    });
}

but as I mentioned it will be used used for generic items.

Questions

• Why TS allows Partial ussage in generic, but not when a type is hard coded?
• How I could implement it? Idealy it should be able to detect which properties are always optional, and which are required if some property is equal to something (in this example if we pass type: 'error' it would be reasonable to also require status since it may or may not be present in object). My current idea is to do Partial<DeepIntersection<T>>, but I got stuck at DeepIntersection part (TypeScript deep intersection of objects union)

EDIT - example of using Combine

Thanks to awesome sugestion provided by @jcalz here TypeScript deep intersection of objects union I was able to make version with hard coded types work:

function updateMessage(
    items: Message[],
    id: number,
    changes: Partial<Omit<Combine<Message>, "id">>
): Message[] {
    return items.map((item) => {
        if (item.id === id) {
            return { ...item, ...changes }; // No error 
        }

        return item;
    });
}

now function knows that it's only safe to update message because even though type is also a property shared by all Message types, changing it without changing other properties could lead to unexpected states. On top of that I also omited id but thats just one extra easy step.

So, in theory I could also add Combine to updateItem (generic one) to add that additional safety, and it would solve the issue. That still doesn't explain why TS doesn't know it's needed though.

Answer 1

I'm going to address this question:

• Why does TS allow Partial usage in a generic type, but not in a specific type?

TL;DR:

• The compiler approximates generic spread with simple intersection types. This approximation is useful but unsound. Your code trips over this unsoundness, and the compiler thus allows it to run with no error, even though it's unsafe.

---

When item and changes are of the specific object types Message and Partial<Message>, the compiler can infer a fairly accurate type for the value {...item, ...changes}:

declare const item: Message;
declare const changes: Partial<Message>;
const spread = { ...item, ...changes };
/* const spread: {
    id: number;
    type: "success";
    message: string;
} | {
    id: number;
    type: "success" | "error";
    message: string;
    status?: number | undefined;
} | {
    id: number;
    type: "success" | "error";
    message: string;
    status: number;
} | {
    id: number;
    type: "error";
    message: string;
    status: number;
} */

Notice how the type of spread is no longer assignable to Message, because it's possible for the type of spread to have a "error" property without a status property:

type Possibility = Exclude<typeof spread, Message>
/* type Possibility = {
    id: number;
    type: "success" | "error";
    message: string;
    status?: number | undefined;
} */

That's why you get the expected error in the specific updateMessage() version. The compiler can see that the result of the spread is not safe to assign to Message.

---

On the other hand, when item and changes are of the generic types T and Partial<T>, the compiler does what it always does when faced with generic spread: it approximates the resulting type with an intersection:

const example = { ...item, a: 123 }
// const example: T & { a: number; }

const spread = { ...item, ...changes };
// const spread: T & Partial<T>

This simple approximation is often good enough. It's great if the spread doesn't end up overwriting any properties. In the example above, if item doesn't have an a property in it, then T & {a: number} is exactly right.

But if the spread does overwrite properties then the intersection can be inaccurate. That's what's happening with spread. The value {...item, ...changes} is assumed to have the type T & Partial<T>, but it has a very good chance of being something else. And the compiler misses this.

If you had a real T & Partial<T>, you'd be justified in returning it where a T is expected. A value of type X & Y is assignable to both X and Y (that's what an intersection means, and why & is the symbol), so a T & Partial<T> is a perfectly valid T. This is why there's no compiler error here.

---

This is one case where TypeScript's type system is unsound. This instance may or may not be considered a bug. Related issue microsoft/TypeScript#42690 is marked as a bug, but it's not obvious what can be done here instead.

It is indeed possible to start synthesizing somewhat more accurate types for generic spreads, see Typescript, merge object types? for one approach for giving types to the Object.assign() method which is similar to object spread.

But these accurate types are complicated, and the soundness improvement might not be worth the usability and performance cost. Perfect soundness is not one of TypeScript's Design Goals (see non-goal #3).

---

Playground link to code