TypeScript doesn't consider different overloads, only picks the last.

[kristof-mattei]

Bug Report

🔎 Search Terms

TypeScript, Generic, Overload resolution

🕗 Version & Regression Information

Always been there for as far as I can go back on TypeScript playground

⏯ Playground Link

Playground link with relevant code

💻 Code

type ArgsType<T> = T extends (...args: infer A) => any ? A : never

type FunctionProperty<T> = {
    [K in keyof T]: T[K] extends IsCallable<T[K]> ? K : never
}[keyof T]

type IsCallable<T> = T extends (...args: any[]) => any ? T : never


function Method<T extends {},
    M extends FunctionProperty<T>,
    A extends ArgsType<Required<T>[M]>,
    >(inst: T, method: M, ...args: A): ReturnType<Required<T>[M]> {

    return inst[method](...args);
}

class Drink {
    public Wine(): Promise<string>
    public Wine(callback: ((result: string) => void)): void
    public Wine(callback?: ((result: string) => void)): void | Promise<string> {
        if (callback) {
            return callback("Wine");
        }

        return Promise.resolve("Wine");
    }

}

(async function () {
    const drink = new Drink()
    // note how the `Method` function only considers the function's implementation
    // we can fix this by making `callback` in the second overload optional, but 
    // that means that we would be able to call the `void` method without a `callback`.
    // not what we want either.
    console.log(await Method(drink, "Wine"))
    Method(drink, "Wine", (res: string) => void console.log(res))
})().then(() => console.log("Done"));

🙁 Actual behavior

Only the last overload's signature is considered.

🙂 Expected behavior

Correct overload being chosen, respecting both arguments (which is where it fails now) and next up based on returntype.

While this is a contrived example to write out in TS, it's much less so when working with external libraries that suffer from this where only the last overload is considered.

[MartinJohns]

Conditional types do not work well with overloads. It will always pick the last signature. This is the intended behavior / a design limitation.

See the last paragraph in the relevant documentation: https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#inferring-within-conditional-types

[Shakeskeyboarde]

I figured out a recursive way of converting a function overload (function signature intersection) into a union of the individual signatures: Playground link

type OverloadProps<TOverload> = Pick<TOverload, keyof TOverload>;

type OverloadUnionRecursive<TOverload, TPartialOverload = unknown> = TOverload extends (
  ...args: infer TArgs
) => infer TReturn
  ? // Prevent infinite recursion by stopping recursion when TPartialOverload
    // has accumulated all of the TOverload signatures.
    TPartialOverload extends TOverload
    ? never
    :
        | OverloadUnionRecursive<
            TPartialOverload & TOverload,
            TPartialOverload & ((...args: TArgs) => TReturn) & OverloadProps<TOverload>
          >
        | ((...args: TArgs) => TReturn)
  : never;

type OverloadUnion<TOverload extends (...args: any[]) => any> = Exclude<
  OverloadUnionRecursive<
    // The "() => never" signature must be hoisted to the "front" of the
    // intersection, for two reasons: a) because recursion stops when it is
    // encountered, and b) it seems to prevent the collapse of subsequent
    // "compatible" signatures (eg. "() => void" into "(a?: 1) => void"),
    // which gives a direct conversion to a union.
    (() => never) & TOverload
  >,
  TOverload extends () => never ? never : () => never
>;

// Inferring a union of parameter tuples or return types is now possible.
type OverloadParameters<T extends (...args: any[]) => any> = Parameters<OverloadUnion<T>>;
type OverloadReturnType<T extends (...args: any[]) => any> = ReturnType<OverloadUnion<T>>;

This may be useful if you want to get all the signatures.

[LukeCSamuel]

@Shakeskeyboarde awesome work! I'll unashamedly be stealing this (:
Might be worth noting for others that if any of the function signatures are themselves generic, then you'll get the classic "Type instantiation is excessively deep and possibly infinite.ts(2589)"