typescript a recursive strongly typed function

From looking at the implementation of func(), I think it would be best to make a Func<T> interface as an overloaded set of call signatures which represents the four different ways you can call it or functions it returns (with or without each of the extend and obj parameters) and what the result should be. A Func<T> is holding onto a result of type T that may or may not come out depending on how you call it:

interface Func<T extends object | undefined> {
  (): T;
  <U extends object>(extend: undefined, obj: U): U;
  <V extends object>(extend: (obj: T) => V): Func<V>;
  <U extends object, V extends object>(extend: (obj: U) => V, obj: U): Func<V>;
}

If you call a Func<T> with no obj argument, then it will operate on the value of type T that it's holding onto. But if you call a Func<T> with an obj argument of type U, then it will operate on that U value instead of T.

If you call a Func<T> with no extend callback, then it will just return the value on which its operating; either T (if no obj is passed) or U (if obj is passed).

On the other hand if you call a Func<T> with an extend callback, that callback will be called on the value on which Func<T> is operating... so the extend callback either takes a T (if no obj is passed) or U (if obj is passed). And whatever type V the extend callback returns, Func<T> will return another function of type Func<V>.

Finally, func itself is evidently a value of type Func<undefined>, since the value it is holding onto is just undefined (if you call func() with no arguments, you get undefined out).

That means we can write this:

const func: Func<undefined> = function func(extend?: any, obj?: any) {
  if (extend) {
    let newObj = extend(obj)
    return ((extend: any, obj = newObj) => func(extend, obj))
  } else return obj
}

Note that I've decided to use a lot of the any type in the implementation since I'm not interested in convincing the compiler that func is actually a Func<undefined>. I'm just claiming it is.

Okay, so let's see it in action:

let f1 = func(undefined, { 'x': 10 });
/* let f1: {
    x: number;
} */
console.log(f1.x.toFixed(2)) // "10.00"

let f2 = func(<T,>(pos: T) => ({ ...pos, y: 10 }), { 'x': 10 })
/* let f2: Func<{ x: number;} & { y: number;}> */
const f2r = f2();
/* const f2r: { x: number; } & { y: number; } */
console.log(f2r.y.toFixed(2)) // "10.00"

Looks good; the compiler understand exactly what is happening with f1() and f2().

But there's an important note about how f2 was produced. The extend callback is of type <T>(pos: T) => T & {y: number}. I had to annotate it as such (or at least the input; the compiler could infer the return type). This is necessary for the compiler to know that whatever is input as pos, a value of the same type with an extra numeric y property comes out. If instead I just called func() with the callback as you had annotated it:

let f3 = func((pos: any) => ({ ...pos, y: 10 }), { 'x': 10 })
/* let f3: Func<any> */
const f3r = f3();
/* const f3r: any */

the compiler would infer that the return type of extend is just any, and extend is of type (pos: any) => any. And once this happens it means that f3 is a Func<any>, and the compiler has forgotten everything you cared about. It's not really the compiler's fault, though; annotating things as any tends to do that; any is infectious that way.

And just to show that we can call the returned functions also:

let f4 = f2((pos) => ({ ...pos, y: 10 }), {});
//let f4: Func<{ y: number; }>

let f5 = f4()

// let f5: { y: number; }
console.log(JSON.stringify(f5)) // {"y":10}

Looks good!

Playground link to code