Regression in Type Inference for functions derived from typeclasses in TypeScript 5.5.x

[gcanti]

What version of Effect is running?

3.4.7 (and @effect/typeclass@0.24.39)

What steps can reproduce the bug?

import * as OptionInstances from "@effect/typeclass/data/Option";
import * as RecordInstances from "@effect/typeclass/data/Record";

const traverse = RecordInstances.Traversable.traverse(OptionInstances.Applicative);

What is the expected behavior?

In TypeScript version 5.4.x, hovering over traverse displays the following type information:

const traverse: {
    <A, R, O, E, B>(f: (a: A) => Option<B>): <TR, TO, TE>(self: ReadonlyRecord<string, A>) => Option<ReadonlyRecord<string, B>>;
    <TR, TO, TE, A, R, O, E, B>(self: ReadonlyRecord<string, A>, f: (a: A) => Option<B>): Option<ReadonlyRecord<string, B>>;
}

What do you see instead?

After updating to TypeScript 5.5.x, the hover information shows a more complex and less intuitive type definition:

const traverse: {
    <A, R, O, E, B>(f: (a: A) => Kind<OptionTypeLambda, R, O, E, B>): <TR, TO, TE>(self: Kind<ReadonlyRecordTypeLambda<string>, TR, TO, TE, A>) => Kind<OptionTypeLambda, R, O, E, Kind<ReadonlyRecordTypeLambda<...>, TR, TO, TE, B>>;
    <TR, TO, TE, A, R, O, E, B>(self: ReadonlyRecord<...>, f: (a: A) => Kind<OptionTypeLambda, R, O, E, B>): Kind<OptionTypeLambda, R, O, E, Kind<ReadonlyRecordTypeLambda<...>, TR, TO, TE, B>>;
}

Additional information

No response

[mikearnaldi]

Potentially related to microsoft/TypeScript#58937

[mikearnaldi]

Also another issue seems to be present:

import type { Kind } from "effect/HKT"
import type { OptionTypeLambda } from "effect/Option"

export type ShouldBeOption<R, O, E, B> = Kind<OptionTypeLambda, R, O, E, B>
// None<B> | Some<B>

previously Option was preserved

[mikearnaldi]

Also Unify on Option is broken:

import type { Option, Unify } from "effect"

type Broken = Unify.Unify<Option.Option<number> | Option.Option<string>>
// Option.None<string | number> | Option.Some<string | number>

[ecyrbe]

Confirm, those libraries relying on HKT interface encoding are broken :

• Fastify Type Providers (1.6M downloads / week)
• Zodios v11 (50k downloads / week)
• Hotscript (132k downloads / week)
• Typeskell (just for learning purpose)

[jakebailey]

This is solely type display, yes? The code compiles the same? It's not a "regression in inference" if so. Not clear what "broken" means otherwise if you're saying this affects all of those libraries.

Consider using https://www.npmjs.com/package/every-ts to check to see where these changed.

[mikearnaldi]

This is solely type display, yes? The code compiles the same? It's not a "regression in inference" if so. Not clear what "broken" means otherwise if you're saying this affects all of those libraries.

Consider using https://www.npmjs.com/package/every-ts to check to see where these changed.

the code compiles but the types produced are more complex than they were, which would make using those features no longer practical

[ecyrbe]

It's appears it also changes resolution on inference.
Since types are not correctly infered (aka simplified), the HKT encoding that could stay internal to the library now need also to be exported.
Like this :

where previously, since inference is simplified, no need to export the HKT plumbing:

An like @mikearnaldi said this makes those lib unusable.

[ecyrbe]

And since inference is not simplified, typescript can't do proper composition of many HKT together.
So it's definitely not just display
Exemple:

[jakebailey]

If this has any type checking effect, it shouldn't be microsoft/TypeScript#58937. A bug report / repro / bisect would be appreciated.

[ecyrbe]

yes, i'll try to bisect this week-end to help you trouble shoot.

[mikearnaldi]

If this has any type checking effect, it shouldn't be microsoft/TypeScript#58937. A bug report / repro / bisect would be appreciated.

That seems to be specific to ReturnType while this is more generic. Note that the same issue that @ecyrbe brought up applies there, if the function argument of ReturnType includes non exported symbols not computing it would lead to the same issue

[adrian-gierakowski]

Got here via twitter: does this negatively affect high level users of effect (who don’t use typeclass module directly)? Asking since I still haven’t upgraded tsc 5.4 => 5.5 and wondering if I should wait until this is resolved. Thanks!

[mikearnaldi]

Got here via twitter: does this negatively affect high level users of effect (who don’t use typeclass module directly)? Asking since I still haven’t upgraded tsc 5.4 => 5.5 and wondering if I should wait until this is resolved. Thanks!

No it shouldn't, it only affect edge cases like match on options but nothing that can't be fixed with some explicit types

[jfet97]

@jakebailey I tried every-ts bisect with bad = main and good = v5.5-beta on the example issued by @gcanti and if I've done everything correctly it is pointing exactly at microsoft/TypeScript/issues/58546 like the other issue.

I set the tsdk with the result of every-ts tsdk and restarted the tsserver at each step of the bisection, so that the hover information was always aligned with the build.

You get lot of bs at the end of the process, so I had to redirect its output from the terminal to a file: