Unbearably slow typescript definitions

Current behavior:

Some of the built-in types cause type-checking and VSCode intellisense feature to be incredibly, painfully slow.

To reproduce:

This only seems to affect large projects. For me that’s working on https://github.com/vanilla/vanilla (working specifically with react components in library/src/scripts, but it reproduces in other areas as well).

I’ve recorded some gifs of the performance degradation.

Situation	Gif
Current Behaviour
With a slight modification of the type

Expected behavior:

Intellisense on a machine as powerful as the one I’m using should be instant. (32Gb of RAM, i9 CPU, lightning fast SSD).

Environment information:

• react version: 16.9.0
• @emotion/css version: 11.1.3

The slowness cause

Typescript has had a lot of issues recently with various libraries replicating CSS or react types. https://github.com/microsoft/TypeScript/issues/34801#issuecomment-767026973

In this case the cause of the slowness in particular seems to come from this piece of code

https://github.com/emotion-js/emotion/blob/master/packages/serialize/types/index.d.ts#L10-L14

export type CSSPropertiesWithMultiValues = {
  [K in keyof CSSProperties]:
    | CSSProperties[K]
    | Array<Extract<CSSProperties[K], string>> // The Extract<> here.
}

It seems the Extract<> on something with as many properties as this CSSProperties is very slow. What I’ve done for my own personal use was to change the code to

export type CSSPropertiesWithMultiValues = {
  [K in keyof CSSProperties]:
    | CSSProperties[K]
    | Array<CSSProperties[K]>>
}

Now this is may not be the correct type of what’s allowed, as it it then allows multiple values an array of values to be passed to properties that don’t support it. My question is until typescript improves the performance of Extract<> in a situation like this, what do we do?

[Andarist]

DO NOT REORDER YOUR CODE HOPING TO IMPROVE PERF.

And you are telling me this after I’ve implemented an eslint rule for this? 😬

On a more serious note though - thank you for explaining this in more detail. I really appreciate it and it makes more sense now to me (even though I would intuitively think that this is resolved in topological order).

[Andarist]

IIRC the problems that were recognized in this thread were, sort of, addressed in TS itself so it should work better with the latest version of TS. If there is anything that we can do to improve the situation - let us know. I’m afraid that we don’t have time resources to investigate what exactly causes a slowdown though.