Type is not checked when using object spread and computed property of type number

[OliverJAsh]

Bug Report

🔎 Search Terms

spread computed property number reduce

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________

⏯ Playground Link

Playground link with relevant code

💻 Code

declare const id: number;

type Acc = { [key: string]: number };
declare const acc: Acc;

// Expected error, but got none. ❌
const acc2: Acc = {
    ...acc,
    [id]: 'invalid',
};

If we change the type of the computed property id from number to string, it works as expected (we get an error).

declare const id: string;

type Acc = { [key: string]: number };
declare const acc: Acc;

// Expected error, and got none. ✅
const acc2: Acc = {
    ...acc,
    [id]: 'invalid',
};

Alternatively, if we remove the spread of acc it works as expected:

declare const id: number;

type Acc = { [key: string]: number };
// declare const acc: Acc;

// Expected error, and got none. ✅
const acc2: Acc = {
    [id]: 'invalid',
};

My workaround for now is to convert the type before it's used as a computed property:

declare const id: number;

type Acc = { [key: string]: number };
declare const acc: Acc;

// Expected error, and got none. ✅
const acc2: Acc = {
    ...acc,
    [id.toString()]: 'invalid',
};

🙁 Actual behavior

See code comments above.

🙂 Expected behavior

See code comments above.

[ajafff]

Probably related to or duplicate of #27273

[andrewbranch]

Related, but this feels more definitely buggy than #27273 because of the : Acc annotation on the object literal... index signatures are weird and will always have some unexpected behaviors, but it seems like this is probably fixable, in the specific case where we have an object literal and a contextual type.

[Andarist]

Hm, this could be fixed without fixing #27273 but it feels to me that perhaps some solution for #27273 is actually desirable and that would potentially fix this case here as well.

I don't feel confident enough in implementing a special handling for this case here. It probably could be done by consulting the contextual type after this call. At the very least It would have to be checked if:

• the result is missing the required index info
• and if the "sources" (left and right types) had the required index info