#Intersection with conditional type causing extremely slow type checking

1 messages · Page 1 of 1 (latest)

last furnace
#

I have a pretty complicated library: https://github.com/xixixao/convex-ents (it's similar to Prisma)
(I'm gonna just describe the issue in-situ, as it's pretty complicated to pull it out into the playground)
All the code I'll mention is in this file: https://github.com/xixixao/convex-ents/blob/c6e88cf7c539fc452f061f5f26c28565be3e2bf2/src/functions.ts
In it I have two intersection types, Ent and EntWriter. I have to use an intersection, because I want to add methods to a POJO (I do this via an intersection between a class and a Record type).
One type should be a subtype of the other (EntWriter should be a subtype of Ent).
The types have a method edge (from the class in the intersection), which returns a conditional type (PromiseEdge and PromiseEdgeWriter respectively), which results in other complicated types, but the subtyping relationship holds.
The library code typechecks fine, but the issue arises when the user of the library tries to assert that EntWriter<> is indeed a subtype of Ent:

const x: Ent<"sometable"> = someEntWriter;

Now TypeScript goes and tries to check the subtyping relationship, starting with the intersection, walking to the conditionals, and to all their branches, and to all the methods of those types, etc. It can take minutes.

I can observe the slowdown by reverting PromiseEdgeWriter to match PromiseEdge exactly, and then changing one branch at a time.

I'm afraid that this is a fundamental limitation of this setup, but I'm curious whether anyone here has any tips on what to try. I already tried:

  • Making the result types of the branches in PromiseEdgeWriter be sub-interfaces of those in PromiseEdge , and only override methods (include the then method to change the Promise type).
  • Making the result types of the branches generic (which is similar but doesn't require overriding the then method)

Thanks!

neon zinc
#

Hey, someone here might be able to help, but I think I would go to github issues or perhaps #compiler-internals-and-api for someone who knows about implementation details and performance

#

it's a bit more technical than the usual questions here.

#

Or mention the thread in #ts-discussion

neon zinc
#

It doesn't sound like anything that should be slow, unless your types are humungous. So could be something optimisable. The other option is to dig into source code if you think it's an opto issue.