Reverse mapped types don't use their constraint types when no candidates are present unlike the regular type parameters #56241

Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   Possible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some casesThe current behavior isn't wrong, but it's possible to see that it might be better in some cases

   on Oct 30, 2023
2. Ryan Cavanaugh (RyanCavanaugh)

   added this to the Backlog milestone on Oct 30, 2023
3. niieani commented on Feb 27, 2025

   

   Bazyli Brzóska (niieani)

   on Feb 27, 2025

   More actions

   Since Ryan Cavanaugh (@RyanCavanaugh) closed #61228 as duplicate, I'm adding the context from that one, since it's slightly different from what is mentioned here:

   🔎 Search Terms

   • tuple inference with function literal
   • inference tuple function and object literal
   • mixing tuple objects and function widening

   🕗 Version & Regression Information

   • This is the behavior in every version I tried (from 4.0.5 to 5.8.1-rc), and I reviewed the FAQ for entries possibly related to this

   ⏯ Playground Link

   Playground

   💻 Code

   interface MatcherObj {
     name: string;
   }
   
   type MatcherFn = (name: string) => boolean
   
   type Matcher = MatcherObj | MatcherFn
   
   type MapTuple<KeysTuple extends unknown[], MapToValue> = {
     [Index in keyof KeysTuple]: MapToValue;
   }
   
   interface Definition<MatchersT extends Matcher[]> {
     matches: [...MatchersT];
     computeValueFromMatches: (
       ...matches: MapTuple<MatchersT, Matcher[]>
     ) => number;
   }
   
   interface Config<Defs extends {[K in keyof Defs]: Definition<any>}> {
     definition: Defs;
   }
   
   function create<Defs extends {[K in keyof Defs]: Matcher[]}>(
     config: Config<{ [K in keyof Defs]: Definition<Defs[K]> }>
   ) {
     // ...
   }
   
   
   create({
     definition: {
       valid: {
         matches: [{ name: "m3" }],
         computeValueFromMatches: (m) => m.length,
       },
       too_mang_args: {
         matches: [{ name: "m1" }, { name: "m2" }],
         // below correctly errors "Target signature provides too few arguments. Expected 3 or more, but got 2."
         computeValueFromMatches: (m1, m2, m3) => m1.length + m2.length,
       },
       not_enough_args: {
         matches: [],
         // below correctly errors "Target signature provides too few arguments. Expected 1 or more, but got 0."
         computeValueFromMatches: (m) => 123
       },
       // valid_using_function: {
       //   matches: [(a) => a === 'x'],
       //   computeValueFromMatches: (m) => m.length
       // },
   
       // as soon as you uncomment 'valid_using_function' all the errors go away, and inference breaks!
     },
   })

   🙁 Actual behavior

   When all elements in the matches tuple are object literals, TypeScript infers an exact tuple type (e.g. [MatcherObj] or [MatcherObj, MatcherObj]), and the signature of computeValueFromMatches enforces the correct number of arguments.

   However, if a function literal (or an object with a function as a property) is included in the tuple—as shown in the commented-out valid_using_function case — the inference for ALL the cases breaks (not just the one property!), as the entire type widens to MatcherObj[].

   This causes the relationship between the number of tuple elements and the number of parameters expected by computeValueFromMatches to be lost, so TypeScript no longer emits errors for other keys when the number of parameters is incorrect.

   🙂 Expected behavior

   TypeScript should preserve the literal tuple type even when a function literal is included.
   In the example case, the tuple length of the matches property should be inferred exactly as provided, so that computeValueFromMatches enforces a parameter count matching the tuple length.

   This behavior should be consistent regardless of whether the tuple elements are object literals or function literals.

   Additional information about the issue

   This issue does not occur when using object literals exclusively in the matches tuple. It only manifests when a function literal is included, suggesting that the inference algorithm incorrectly widens the tuple type in that scenario.

   What's even more bizarre, even if you change the Matcher type to be an object whose a property can be a function, the same issue occurs! i.e.

   type Matcher = { name: string | (name: string) => boolean }

   As soon as any of the defined matches uses a function under the name property, e.g. { name: () => true }, causes same widening behavior!

   I have thoroughly searched the TypeScript repository and online discussions but have not found a related issue.
4. Ryan Cavanaugh (RyanCavanaugh)

   added

   Domain: Mapped TypesThe issue relates to mapped typesThe issue relates to mapped types

   on Oct 16, 2025