Upgrading jss and react-jss from 10.0.2 to 10.0.4 breaks TypeScript compile step.

We’re currently trying to upgrade our React-based design system thenativeweb-ux which uses JSS and react-jss. We’d like to upgrade from 10.0.2 to 10.0.4. Unfortunately this upgrade breaks the TypeScript compile step.

Expected behavior:

Compiling a React- and TypeScript-based codebase should run in a reasonable amount of time.

Describe the bug:

With earlier versions (e.g. 10.0.0, 10.0.1, 10.0.2) the TypeScript performance was solid. The upgrade to version 10.0.4 caused the compliation process to hang until it completely crashes the Node.js process since it’s running out of memory. See the the logs of the Github action runs the compilation step (The task is called ‘Run roboter’).

Codesandbox link:

The whole repo is Open Source, so we can share all the code and CI logs. Here is the PR that performs the upgrade. The master branch is still on 10.0.2 and happily compiling. Again here are the logs of the Github action that runs the compile step. It’s possible to clone the repo locally, run npm install, and then npx roboter build or npx tsc.

Versions:

• jss: 10.0.4
• OS: macOS and Linux

Insights so far:

• The actual type checking seems to work. When you run npx tsc --noEmit --diagnostics (which will only type check but not output any files) the process completes in 7-8 seconds.
• We also did some tests with 10.0.3 which also caused this performance. So it seems like something introduced in 10.0.3 might be the cause of this issue.

Maybe somebody else is experiencing issues like this? Anyway, we’re grateful for any hints into what might be the cause for this behaviour.

[mattwagl]

I had another look at the defintion file to better identify the bottleneck. I have some additional insights I wanted to share.

My first guess was that the bottleneck happens because of this intersection of types:

type JssStyleP<S> = CssProperties & {
  [key: string]: FnValue<JssValue | S>
}

However this is not the actual root of the problem. Because you can change this definition to:

type JssStyleP<S> = NormalCssProperties & {
  [key: string]: FnValue<JssValue | S>
}

…and the bottleneck is gone. That lead me to the question: what is the difference between the two types CssProperties and NormalCssProperties? Here’s what they look like:

type NormalCssProperties = css.Properties<string | number>
type CssProperties = {[K in keyof NormalCssProperties]: FnValue<NormalCssProperties[K]>}

So CssProperties is a mapped type which seems like is needed to set dynamic values in a style definition. In this mapped type we’re mapping over all the keys of NormalCssProperties. If you grap the keys by hand like this…

type KeysOfNormalCssProperties = keyof NormalCssProperties;

… you see that NormalCssProperties has about 750 keys.

This does not seem much but it’s enough to completely slow down the compile step. So the problem here is: We’re creating a mapped type that maps over 750 keys. Unfortunately I haven’t found a solution yet on how to avoid or prevent this from happening. But hopefully this information is helpful to others.

[mattwagl]

I hade some time today to dig a bit deeper into the problem. I tried to make small changes inside the main definiton file of the JSS package in order to track down a possible bottle neck.

I also found other TypeScript issues, e.g. this one that originated in the styled-components ecoystem that also reported slow TypeScript compliation times. In this particular thread there’s a comment pointing out that

… performance impact is caused by a large union of types (eg, the union of all possible jsx components)…

So scanned the definition file for possibly large unions of types and found this line. So when I change this line from…

// Jss Style definitions
type JssStyleP<S> = CssProperties & {
  [key: string]: FnValue<JssValue | S>
}

…to…

// Jss Style definitions
type JssStyleP<S> =  {
  [key: string]: FnValue<JssValue | S>
}

… the bottleneck is gone and compilation time is back to normal. Also the code editor is responsive again and is able to report TypeScript issues again.