Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   changed the title [-]False-positive when using object spread with a generic type[/-] [+]Missing error when mistyped value overwrites property of spreaded generic type parameter[/+] on Feb 8, 2021
2. Ryan Cavanaugh (RyanCavanaugh)

   added

   BugA bug in TypeScriptA bug in TypeScript

   on Feb 8, 2021
3. Ryan Cavanaugh (RyanCavanaugh)

   added this to the Backlog milestone on Feb 8, 2021
4. misuken-now commented on Mar 15, 2021

   

   misuken (misuken-now)

   on Mar 15, 2021

   Last edited by misuken-now

   More actions

   I often run into the same problem and have trouble with it.

   Patterns encountered in React.

   import * as React from "react";
    
   export const Component: React.VFC<{ id?: string }> = <T extends { id?: string }>(props: T) => {
     <>
       1. <div {...props} />      　✅ OK
       2. <div id={1} />            ✅ Error
       3. <div {...props} id={1} /> 🤔 OK 
     </>;
    
     const r1: T = { ...props, id: 1 }; // 🤔 OK
    
     return null;
   }

   playground

   The cause seems to be related to the intersection type and never, as shown below.

   import * as React from "react";
   
   // generic type
   function f1<T extends { id: string; id2?: string }>(props: T) {
       return { ...props, id: 1 };
   }
   const R11 = f1({ id: "" }); // R11 = { id: string; } & { id: number; }
   const R12 = <div {...R11} />; // 🤔 OK
   
   // no generic type
   function f2(props: { id: string }) {
       return { ...props, id: 1 };
   }
   const R21 = f2({ id: "" }); // R21 = { id: number; }
   const R22 = <div {...R21} />; // ✅ Error

   playground

   { id: string; } & { id: number; } will evaluate to { id: never }.

   declare const v1: { id: never };
   const v2: { id: string } = v1; // ✅ `never` is correct because it can be assigned to a `string`.

   playground

   conditional types extends are all false, so { id: number } cannot be assigned to { id: string }.

   export type R11 = ReturnType<() => { id: number } extends { id: string } ? true : false>; // false
   export type R12 = ReturnType<() => { id?: number } extends { id: string } ? true : false>; // false
   export type R13 = ReturnType<() => { id: number } extends { id?: string } ? true : false>; // false
   export type R14 = ReturnType<() => { id?: number } extends { id?: string } ? true : false>; // false
   
   export type R21 = ReturnType<<T extends { id: string }>() => { id: number } extends T ? true : false>; // false
   export type R22 = ReturnType<<T extends { id?: string }>() => { id: number } extends T ? true : false>; // false
   export type R23 = ReturnType<<T extends { id: string }>() => { id?: number } extends T ? true : false>; // false
   export type R24 = ReturnType<<T extends { id?: string }>() => { id?: number } extends T ? true : false>; // false

   playground

   If there was a check for assignability before processing with the intersection type, it would work as expected, wouldn't it?
5. misuken-now commented on Mar 15, 2021

   

   misuken (misuken-now)

   on Mar 15, 2021

   Last edited by misuken-now

   More actions

   I was able to write a function to check the problem.

   function f1<T extends { id: string }, U extends { id: number }>(props: T, props2: U) {
       function checkType1<V, U>(props: U & {[P in keyof V]?: V[P]}) { return props; };
       function checkType2<V, U>(props: U & {[P in keyof V]?: V[P]}) { return props as U; };
       const R11 = checkType1({ ...props, ...props2 }); // never ✅ Argument Error
       const R12 = checkType1({ ...props, id: 1 });     // never ✅ Argument Error
       const R13 = checkType1({ ...props, id: "" });    // T & { id: string; } & { id?: string | undefined; } ✅ OK
   
       const R21 = checkType2({ ...props, ...props2 }); // T & U               ✅ Argument Error
       const R22 = checkType2({ ...props, id: 1 });     // T & { id: number; } ✅ Argument Error
       const R23 = checkType2({ ...props, id: "" });    // T & { id: string; } ✅ OK
   }

   playground
6. vkarponen commented on Oct 4, 2021

   

   Ville-Kalle Arponen (vkarponen)

   on Oct 4, 2021

   More actions

   It would seem that the problem appears also without generics:

   function test(param: { [key: string]: (string | number) }) {
       const stringValues: { [key: string]: string } = {
           foo: 'bar',
           ...param
       };
       console.log(stringValues);
   }
   

   is falsely not considered an error but if you remove foo: 'bar', from the above then TS considers that to be an error as it should.
7. misuken-now commented on Oct 7, 2021

   

   misuken (misuken-now)

   on Oct 7, 2021

   More actions

   In situations where generics are not used, the use of "Object.assign" may be a solution.

   function test(param: { [key: string]: (string | number) }) {
     // Type '{ foo: string; } & { [key: string]: string | number; }' is not assignable to type '{ [key: string]: string; }'.
     // 'string' index signatures are incompatible.
     //   Type 'string | number' is not assignable to type 'string'.
     //     Type 'number' is not assignable to type 'string'.(2322)
     const stringValues: { [key: string]: string } = Object.assign({}, {
       foo: 'bar'
     }, param);
     console.log(stringValues);
   }

   playground
8. teynar commented on Nov 14, 2022

   

   Teynar (teynar)

   on Nov 14, 2022

   More actions

   I am also experiencing this issue and I feel quite surprised since this looks like a fairly common case when using reduce with the spread operator.

   function foo<T extends string>(keys: T[]): Record<T, number> {
     return keys.reduce((acc, key) => {
       return {
         ...acc,
         [key]: 'string' // this is not a number, but there is no error
       }
     }, {} as Record<T, number>);
   }

   TypeScript Playground

   👍React with 👍4Reacted by Raúl Ibáñez, enricrp8, Sʜɪᴍᴜʀᴀ Yū and KostyanWest

   👀React with 👀1Reacted by Raúl Ibáñez
9. kumikumi commented on Aug 23, 2023

   

   Mikko Ankkala (kumikumi)

   on Aug 23, 2023

   Last edited by kumikumi

   More actions

   This is probably related to the same issue:
   Playground Link
10. Ryan Cavanaugh (RyanCavanaugh)

    added

    Domain: check: Type InferenceRelated to type inference performed during signature resolution or `infer` type resolutionRelated to type inference performed during signature resolution or `infer` type resolution

    on Oct 16, 2025
11. Wojciech (wnadurski)

    marked Overriding fields of a generic object using spread operator results in incorrect types #62831 as a duplicate of this issue on Dec 4, 2025