Spread operator allows invalid return type in record data types

🔎 Search Terms

spread operator, return type mismatch on record of functions

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries. Nothing related was mentioned. I've tried 3.3, 4.0, 5.0 and 5.8.3 and got the same result.

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.8.3#code/C4TwDgpgBAYgdgHgJIBooHkB8UC8UDeUokAXFAEQBmc5A3FNWQBQCWcYArsGUgJS7Z0UAL60AUGOLR4AJQgBjAPYAnACbI0WXFDlK1CAM7BlbAOZp4GjNgA+UDnFURKbCKszixlB-OAtFcESKsgoq6qjWTGJQUACGvv5wBmS6YYbGZmis7Fw8-DiCUHYOTi5wbphivGQheuGa2PjRRAAWyooA7lDlXQCiyu3KTLziwhJKScBENXCp+gBuiiyqaHAcALYARhDK2HhNMbFkhFJkVDRojFDDAlAATCJoAPRPUAgAtFBK6+sQcH5wUxQRRcVosAxQAA2rigyggBg4kOAELYcUCO0GUFRwBa0Gh5Sg20hnWaADpycBgrNQmomIRNsx8thyABmcgiXgoMSiMRAA

💻 Code

type Fn<I, O> = { type: "fn"; fn: (input: I) => O };

type FnRecord<I, O> = Record<string, Fn<I, O> | undefined>;

function toFnRecord<I, O>(
  actions: Record<string, (input: I) => O | undefined>
): FnRecord<I, O> {
  throw new Error();
}

const t: FnRecord<void, number> = {
  a: { type: "fn", fn: () => 2 }, // <- commenting out this line results in an error in the line below
  ...toFnRecord({ b: () => "3" }),
}

🙁 Actual behavior

No error was reported

🙂 Expected behavior

Expect the following type mismatch error message. This is reported if I comment out the entry without spread operator (a: { type: "fn", fn: () => 2 },)

Type '{ [x: string]: Fn<void, string> | undefined; }' is not assignable to type 'FnRecord<void, number>'.
  'string' index signatures are incompatible.
    Type 'Fn<void, string> | undefined' is not assignable to type 'Fn<void, number> | undefined'.
      Type 'Fn<void, string>' is not assignable to type 'Fn<void, number>'.
        Type 'string' is not assignable to type 'number'.(2322)

Additional information about the issue

Similar to #61754, but this example does not involve any explicit generic subtyping constraints (extends).

I'm not sure if this is related to #10727.

I'd like to know any workaround that can prevent this type error happening at runtime. I've run into this multiple times with the same pattern used in my codebase and got very surprised each time.