Optimisations to inference in 0.32 seems to cause `ts(2589)` with composite types. about typebox HOT 16 OPEN

@Gnuxie Hi,

I couldn't see anything specifically from #689 that would be causing this, but I could be missing something.

There has been some recent updates made to Composite to further replicate type evaluation in TypeScript (that is to say, TypeBox is trying to compute the intersection of all types passed to Composite such that the output schema / type is an evaluated object type and not a allOf representation as would be the case for Intersect). However, the Composite evaluation is an extremely expensive thing to compute, and I think when tagged with ReturnType inference (instantiation expressions as per your implementation), this is likely pushing out the extents of the type system.

The recent updates for Composite were to do with Union evaluation. You can read about some of the context here #789. I believe these updates went out on 0.32.16, so if you can try 0.32.15 and just let me know if you still see the same issue, I may reinvestigate using the matrix-protection types as a basis for testing.

Workaround

Granted, this could be a misuse of the composite type, and I'm not sure where to go from here

So, much of the issues here would be to do with TypeBox doing deep type evaluation on the Composite types. If it's reasonable to do so, you can swap from Composite to Intersect. The Intersect type should have the same assertion characteristics as Composite, but the schematics are a bit more "extreme" as each Intersect type is expressed via JSON Schema allOf keyword.

Here's a working version of the matrix-protection types using Intersect instead of Composite.

TypeScript Link Here

If you just want to test version 0.32.15 and let me know how that helps solve things, that would be great. I don't know if I'm going to be able to revert Composite back to a previous version (as the current implementation is closer the envisioned computed type), but do think there's potential to further optimize the type for the implementation you've provided. There is some pending work to do with respect to deep type evaluation (of which Composite would be involved), but I don't envision optimizations making it out until TypeBox reaches 0.33.x (which is a fair way off)

For now, give Intersect a try (which will keep you on the latest versions) and just let me know if you still run into issues on 0.32.15, I'll do some digging based on your feedback.

Cheers!
S

from typebox.

Hi, thanks for the speedy response, I'll see what happens in 0.32.15 and report back.

Workaround

For now though, I want to add some context for why I originally moved away from Intersect, and there are two reasons.

The first is it's less helpful dealing with the typescript union type when trying to debug an issue, since obviously they can become so massive. It can be very difficult to see what is wrong based on the output typescript gives when working with what are believed to be (by me) compatible types. And then VSCode would also expand references to types into a massive type literal when using VSCode's feature to add missing methods when implementing classes in interfaces, and I would get annoyed trying to delete them. Which yes, is probably a silly reason 😓.

e.g.

interface Timeline {
    addEvent(event: RoomEvent): void;
}

class StandardTimeline implements Timeline {
    addEvent(event: { ... }
        & { .... }
        & { .... }
    ) {
        throw new TypeError("Unimplemented");
    }
}

However, the Composite evaluation is an extremely expensive thing to compute, and I think when tagged with ReturnType inference (instantiation expressions as per your implementation), this is likely pushing out the extents of the type system.

I see, I don't really understand how the type system works but I trust you. I'll follow up shortly

from typebox.

The problem seems to be introduced within 0.32.0.

from typebox.