Typescript falls back to the default value of generic type for no reason

Sorry if the title is not very obvious. I don't know what is the problem so I couldn't come up with a good question. This is a simplified version of the problem that I'm struggling with:

type Key = unknown[];

type Option<TKey extends Key> = {
  key: TKey;
  updateKey: (v: TKey) => TKey;
};

type Getter = <Value>(v: Value) => Value

function createConfigWithOption<TKey extends Key>(
  getOptions: ((g: Getter) => Option<TKey>)
) {
}

createConfigWithOption receives a function whose first parameter is a getter function (doesn't matter what it does) and returns an option object. The option object has a key key and an updateKey function. The input and output of updateKey should be inferred from the key.

It works correctly if I don't use the getter:

createConfigWithOption(() => ({
  key: ["1"],
  updateKey: (currentKey) => {
    const a = currentKey[0];
    //    ^? const a: string

    return [];
  },
}));

But it falls back to the default value of Key when I use the getter:

createConfigWithOption((get) => ({
  key: ["1"],
  updateKey: (currentKey) => {
    const a = currentKey[0];
    //    ^? const a: unknown
    
    return [];
  },
}));

Here is a Typescript playground if you want to try it out yourself.

I've been scratching my head for several hours to understand what's going on but didn't find an answer.

See microsoft/TypeScript#47599 for an authoritative description of this issue.

TypeScript's type inference algorithm isn't perfect by any means; it's effectively a collection of heuristic rules that works well over a wide range of use cases, but there are unfortunately situations where it fails to infer something that a human developer would see as obvious. One place where things can go awry is if the compiler needs to infer generic type arguments at the same time it needs to contextually infer callback parameter types.

The difference between

createConfigWithOption(() => ({
  key: ["1"],
  updateKey: (currentKey) => {
    const a = currentKey[0];
    //    ^? const a: string

    return [];
  },
}));

and

createConfigWithOption((get) => ({
  key: ["1"],
  updateKey: (currentKey) => {
    const a = currentKey[0];
    //    ^? const a: unknown
    
    return [];
  },
}));

is that in the latter, the callback passed to createConfigWithOption has a callback parameter get whose type the compiler wants to infer for you. That makes the whole callback function context sensitive. Generally speaking, if the compiler doesn't know the parameter type of a function, it can't know the types of what's going on inside the function either. The current algorithm tends to delay context sensitive inferences until after generic type arguments are inferred. But this is a problem, since leaving the callback as a black box means that the compiler has no idea what to infer for the E generic type parameter, so it falls back to the constraint, after which get is inferred properly... but it's too late, since E is wider than you want.

Note that in this particular instance, it turns out that get is not used anywhere inside the function body, so in fact nothing actually depends on its type. But the compiler doesn't do much of an inspection into the function body to check for that sort of thing. So using (get)=> like that messes up inference for you.

So that's what's going on. There have been recent improvements in this sort of circular contextual-and-generic inference, as described in microsoft/TypeScript#48538, but they can't address every possible situation, and your code is one of those places that still doesn't work as you want.

The workarounds here are either to leave it out entirely like ()=> as in your first example, or to explicitly annotate it with its type so the compiler doesn't have to infer it:

createConfigWithOption((get: Getter) => ({
  key: ["1"],
  updateKey: (currentKey) => {
    const a = currentKey[0];
    //    ^? const a: string
    
    return [];
  },
}));

Playground link to code