Trouble typing `zip`, and generally predicting when inference breaks in overloaded functions with generics

I sometimes have this kind of issue but I don't know exactly why the inference does not work.

In this case zip returns the correct type when applied directly, but not when applied through pipe and I have no idea why.

declare const zip: {
    <A, B>(input: readonly [readonly A[], readonly B[]]): [A, B][],
    <A, B, C>(input: readonly [readonly A[], readonly B[], readonly C[]]): [A, B, C][],
    <A, B, C, D>(input: readonly [readonly A[], readonly B[], readonly C[], readonly D[]]): [A, B, C, D][],
    <A extends readonly any[]>(input: readonly A[]): A[0][][],
};

declare const pipe:  <A, B>(a: A, f: (a: A) => B) => B;

declare const x: [number[], string[], boolean[]];

const foo = pipe(x, zip);
//     ^? foo: any[][]
const bar = pipe(x, x => zip(x))
//     ^? bar: [number, string, boolean][]

playground
It's not that big of a deal, but it really puzzles me as it can leat to time wasted understanding why something does not compile, or efforts wasted trying to type something for it to not behave as intended in the end.

This pipe function by the way is an extract of the following, which works in most cases (not this one obviously), but is a little hard to look at

const pipe: {
    <A>(
        a: A
    ): A
    <A, B>(
        a: A,
        f: (a: A) => B
    ): B
    <A, B, C>(
        a: A,
        f: (a: A) => B,
        g: (b: B) => C
    ): C
    <A, B, C, D>(
        a: A,
        f: (a: A) => B,
        g: (b: B) => C,
        h: (c: C) => D
    ): D
    <A, B, C, D, E>(
        a: A,
        f: (a: A) => B,
        g: (b: B) => C,
        h: (c: C) => D,
        i: (d: D) => E
    ): E
    <A, B, C, D, E, F>(
        a: A,
        f: (a: A) => B,
        g: (b: B) => C,
        h: (c: C) => D,
        i: (d: D) => E,
        j: (e: E) => F
    ): F
    <A, B, C, D, E, F, G>(
        a: A,
        f: (a: A) => B,
        g: (b: B) => C,
        h: (c: C) => D,
        i: (d: D) => E,
        j: (e: E) => F,
        k: (f: F) => G
    ): G
    <A, B, C, D, E, F, G, H>(
        a: A,
        f: (a: A) => B,
        g: (b: B) => C,
        h: (c: C) => D,
        i: (d: D) => E,
        j: (e: E) => F,
        k: (f: F) => G,
        l: (g: G) => H
    ): H
    <A, B, C, D, E, F, G, H, I>(
        a: A,
        f: (a: A) => B,
        g: (b: B) => C,
        h: (c: C) => D,
        i: (d: D) => E,
        j: (e: E) => F,
        k: (f: F) => G,
        l: (g: G) => H,
        m: (h: H) => I
    ): I
    <A, B, C, D, E, F, G, H, I, J>(
        a: A,
        f: (a: A) => B,
        g: (b: B) => C,
        h: (c: C) => D,
        i: (d: D) => E,
        j: (e: E) => F,
        k: (f: F) => G,
        l: (g: G) => H,
        m: (h: H) => I,
        n: (i: I) => J
    ): J
}

You may think that, hey, with a mapped type you can come up with something like this (don't pay attention to the details)

import { Lift, free, Init, Tail } from 'free-types';

declare const pipe: {
    <A,B>(a: A, ...fns: Fns<[A, B]>): B
    <A,B, C>(a: A, ...fns: Fns<[A, B, C]>): C
    <A,B, C, D>(a: A, ...fns: Fns<[A, B, C, D]>): D
    <A,B, C, D, E>(a: A, ...fns: Fns<[A, B, C, D, E]>): E
    <A,B, C, D, E, F>(a: A, ...fns: Fns<[A, B, C, D, E, F]>): F
    <A,B, C, D, E, F, G>(a: A, ...fns: Fns<[A, B, C, D, E, F, G]>): G
    <A,B, C, D, E, F, G, H>(a: A, ...fns: Fns<[A, B, C, D, E, F, G, H]>): H
    <A,B, C, D, E, F, G, H, I>(a: A, ...fns: Fns<[A, B, C, D, E, F, G, H, I]>): I
    <A,B, C, D, E, F, G, H, I, J>(a: A, ...fns: Fns<[A, B, C, D, E, F, G, H, I, J]>): J
};

type Fns<Fs extends [unknown, ...unknown[]]> = Lift<free.UnaryFunction, [Init<Fs>, Tail<Fs>]>

playground

but it is only going to work on monomorphic functions for some reason. I experimented with simpler designs, but basically at one point there will be one indirection that will loose the compiler and I can't really predict it. The longer/simpler version of pipe is the one you find in most FP libraries, and for good reason apparently.

Can you explain the zip situation? If you have thoughts on the more involved pipe version, feel free to share them.

TL;DR Inference to overloaded functions gives you the last call signature with any generics erased. It's a design limitation of TypeScript.

Since zip() is an overloaded function with multiple call signatures, inferences involving it only consider the last call signature, instead of choosing the "appropriate" call signature that you'd get when you call zip() directly. This is a known design limitation of TypeScript, as described in microsoft/TypeScript#50432 (among others).

So you get behavior similar to what would happen if zip were just

declare const zip: {
<A extends any[]>(input: A[]): A[0][][],
};

Although in that case, you'd actually get a more specific result:

declare const x: [number[], string[], boolean[]];
const foo = pipe(x, zip);
//     ^? const foo: (string | number | boolean)[][]

But because you have overloads, the inference actually erases the generic type parameter when matching, as described in microsoft/TypeScript#52916 (which might be a bug but there's probably no good way to change it, at least according to that issue), and therefore the type parameter is replaced with its constraint. Meaning it actually behaves like

declare const zip: {
(input: any[][]): any[][0][][],
};

which produces

const foo = pipe(x, zip);
//     ^? const foo: any[][]

as you've seen.

Playground link to code