Import Node type kills TypeScript performance

[cedeber]

Describe the Bug

Doing import type {Node} from "reactflow"; kills the TypeScript performance. Importing all other types looks fine.
I feel like the conflict with the generic Node type may be the culprit.

This is my setup of TypeScript for the novelties of TS5.1. For the rest I am just using ESNext setup.

{
    "verbatimModuleSyntax": true,
    "allowImportingTsExtensions": true,
    "moduleResolution": "bundler"
}

PS: It happens with the last version of TypeScript within VSCode or IntelliJ. So it's definitely not an IDE issue. And it happens only on files that import "reactflow". All the other files work as fast as expected.

Your Example Website or App

No response

Steps to Reproduce the Bug or Issue

Well, just import type Node

Expected behavior

Keep TS fast.

Screenshots or Videos

No response

Platform

Windows

Additional context

No response

[cedeber]

I tried with different versions of TypeScript 5 too. And the same issue happens. But quickly checking the source, I don't see something wrong to be honest. I am also wondering if TypeScript itself is struggling with the generic Node types.

So, am I the only one having this issue?

[moklick]

I never encountered this issue and it isn't something special we are doing here. React for example also export a type called MouseEvent and there is a generic one. Can you spot a difference if you do import type { Node as RFNode } from "reactflow"; for example?

[cedeber]

We tried the RFNode as well and it behaves the same.

[cedeber]

I probably have to create a simpler project with the same TS setup and see. I'll do that a bit later.

[cedeber]

Yeah, as expected on a small project it doesn't affect the performance. In our app, we have hundreds of files. It's the first that I see that, and it only affects files related to this import. That's why I created the ticket here. Please keep it open until I found why. If not, I'll close it but give us few days. Thanks.

[cedeber]

Ok, some progress here. Looks like immer doesn't like it much. The bug is mostly visible when used with zustand and the immer middleware. If I remove the immer middleware it works like a charm.

I've seen that you are using zustand internally too, but not immer, right?

On the immer side, there some other libraries used with immer which are causing a recursive, if not infinite, type loop, which may explains the slowness. See immerjs/immer#839 and immerjs/immer#990

Looks like an issue on the immer side, so I'm closing this one.