An argument for 'reviver' was not provided.

[ntucker]

An argument for 'reviver' was not provided.

[ntucker]

Yeah that looks like a reasonable solution.

Just to provide some clarity about the tests - while the 'as const' does wrap the whole tuple of tuples; since test.each is iterating through the first array; the function will end up acting on either - which is why it ends up in a union type. Though really I was just trying to create another function with the same usage as fromJS. (I never call it with a second arg).

I think the generation of a full union type is correct; but the fact that this breaks polymorphic functions seems to be the bug in TypeScript.

[ntucker]

Real world just-upgrade breaking test suite: reactive/data-client#2424 CI: https://app.circleci.com/pipelines/github/data-client/rest-hooks/9617/workflows/48caf48a-179e-4b43-a1db-a1388047347a/jobs/61606

[jdeniau]

I tried some things, and it's kind of funny (or weird)

import { fromJS } from 'immutable';

const create = [(data: any) => data, fromJS][1];
create({}); // do error

const create2 = [fromJS][0];
create2({}); // works fine

const create3 =([(data: any) => data, fromJS] as const)[1];
create3({}); // works fine

const create4 = [(data: any, useless = undefined) => data, fromJS][1];
create4({}); // works fine

tsplay example

In the first example, the created array has a type like (function1|function2)[], while the second has a function1[] type and the last one is the tuple [function1, function2].

I see in your test stack that you already use a as const, but it seems that by passing the createInput function as a second parameter, it seems to force fromJS to be a precise type and loose the two possible overload here.

[jdeniau]

After some tests, I think #1936 does fix this and is a better declaration file for me :

• it keeps the FromJS best possible type with object,
• it fallbacks to Collection<unknown, unknown>,
• if type is hard (like you case), it fallback to any