Definitelytyped: [@types/styled-components] Performance issues on compiler

Created on 2 Apr 2019  ·  37Comments  ·  Source: DefinitelyTyped/DefinitelyTyped

Adding the latest version of @types/styled-components to an existing project causes build times to go up by about 1-2 minutes, by using the latest [email protected].

By using this seed repo, I've tested the following versions:

w/o     2.3s
4.0.0   5.6s
4.1.0   8.0s
4.1.5   8.0s
4.1.10  10.1s
4.1.11  90.1s
4.1.12  97.1s

My machine is a Linux 4.18.0 (Ubuntu 18.10) laptop, with a i7-6700HQ CPU @ 2.60GHz

It seems clear that the release 4.1.11 is what's causing this performance issue. The PR for this release is #33061. As of why, I really don't know - I tried to dig into the internals of the compiler to see where it was getting stuck at, but I couldn't understand it.

  • [x] I tried using the @types/xxxx package and had problems.
  • [x] I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
  • [x] I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
  • [x] [Mention](https://github.com/blog/821-mention-somebody-they-re-notified) the authors (see Definitions by: in index.d.ts) so they can respond.

    • Authors: @eps1lon @Igorbek @Jessidhia

Most helpful comment

@RyanCavanaugh reopen?

All 37 comments

Does this also happen with typescript 3.3?

I experienced same issue

package.json

devDependency

"@babel/core": "^7.4.0",
"@babel/plugin-proposal-class-properties": "^7.4.0",
"@babel/plugin-syntax-dynamic-import": "^7.2.0",
"@babel/plugin-transform-async-to-generator": "^7.4.0",
"@babel/preset-env": "^7.4.2",
"@babel/preset-react": "^7.0.0",
"@babel/preset-typescript": "^7.3.3",
"babel-jest": "^24.5.0",
"babel-loader": "^8.0.5",
"babel-plugin-styled-components": "^1.10.0",
"css-loader": "^2.1.1",
"file-loader": "^3.0.1",
"html-webpack-plugin": "^3.2.0",
"jest": "^24.5.0",
"mini-css-extract-plugin": "^0.5.0",
"node-sass": "^4.11.0",
"react-svg-loader": "^2.1.0",
"regenerator-runtime": "^0.13.2",
"sass-loader": "^7.1.0",
"style-loader": "^0.23.1",
"ts-loader": "^5.3.3",
"typescript-tslint-plugin": "^0.3.1",
"webpack": "^4.29.6",
"webpack-cli": "^3.3.0",
"webpack-dev-server": "^3.2.1"

dependency

"@babel/polyfill": "^7.4.0",
"@loadable/component": "^5.7.0",
"@types/loadable__component": "^5.6.0",
"@types/react": "^16.8.10",
"@types/react-dom": "^16.8.3",
"@types/react-router-dom": "^4.3.1",
"@types/styled-components": "4.1.5",
"axios": "^0.18.0",
"react": "^16.8.6",
"react-dom": "^16.8.6",
"react-router": "^5.0.0",
"react-router-dom": "^5.0.0",
"styled-components": "^4.2.0",
"styled-normalize": "^8.0.6",
"typescript": "^3.4.1"

My problem is that it looks like webpack & webpack-dev-server can not parse @types/styled-components. Because when use just styled-components, there was no problem. It always happen when use @types/[email protected] same time.

Before seeing issue of @voliva, I found infinite loop problem of webpack because it use cpu resource 100%.

After changing @types/styled-compoents version to 4.1.5, it looks like everything is ok.

@eps1lon: Nope, typescript 3.3 is fine; specifically, it looks like the issue starts under release 3.4.0-dev.20190226.

Using @voliva's seed repo, I believe I've pinpointed the issue to the recursive usage of OmitU, added in @types/styled-components release 4.1.1. Here is its definition:

type OmitU<T, K extends keyof T> = T extends any ? PickU<T, Exclude<keyof T, K>> : never;

And here are both of the places OmitU is used in index.d.ts:

Definition of WithOptionalTheme

type WithOptionalTheme<P extends { theme?: T }, T> = OmitU<P, "theme"> & {
    theme?: T;
};

Usage of WithOptionalTheme (in the definition of StyledComponentProps)

WithOptionalTheme<
    OmitU<
        ReactDefaultizedProps<
            C,
            React.ComponentPropsWithRef<C>
        > & O,
        A
    > & Partial<PickU<React.ComponentPropsWithRef<C> & O, A>>,
    T
>

Something about the union-distributed OmitU mapping over another OmitU seems to be tripping up the compiler. If either or both of these instances is replaced with a regular Omit that does not distribute over unions, the compile time is reduced to a reasonable 10 seconds or so under typescript 3.4.1.

(Note that the ReactDefaultizedProps type also references PickU, which may help to explain the especially long running times in the second row of the table below.)

To test this, I swapped out one or both of the distributed OmitUs with one of the following:

type OmitPickU<T, K extends keyof T> = PickU<T, Exclude<keyof T, K>>;
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

Here is time yarn tsc run against typescript 3.4.1, 3.4.0-dev.20190226, and the immediate prior release, 3.4.0-dev.20190223:

| WithOptionalTheme definition | WithOptionalTheme usage | typescript 3.4.1 | typescript 3.4.0-dev.20190226 | typescript 3.4.0-dev.20190223 |
| --- | --- | --- | --- | --- |
| OmitU | OmitU | 1m28.984s | 0m55.853s | 0m6.031s |
| OmitU | OmitPickU | 2m49.492s | 1m49.457s | 0m5.961s |
| OmitPickU | OmitU | 1m10.313s | 0m35.278s | 0m6.125s |
| OmitPickU | OmitPickU | 0m10.501s | 0m6.947s | 0m6.055s |
| OmitU | Omit | 0m9.611s | 0m6.781s | 0m6.102s |
| Omit | OmitU | 0m10.471s | 0m7.451s | ...etc |
| OmitPickU | Omit | 0m9.654s | 0m6.796s | |
| Omit | OmitPickU | 0m8.990s | 0m6.485s | |
| Omit | Omit | 0m9.730s | 0m6.815s | |

Running times for typescript 3.3.3 and 3.3.4000 are consistent with 3.4.0-dev.20190223 -- roughly 6 seconds across the board.

I'm not familiar enough with styled-components to propose a solution, but I hope this data helps!

I can confirm I have the same issue. Downgrading @types/styled-components to 4.1.5 worked for me as well. I'm on typescript 3.4.1

@michsa I was expecting some reduction but not a 10x. Since this was introduced in typescript 3.4 could you open an issue in the typescript repo as well? I would like to make sure we don't revert a bug fix if it's a regression that should be fixed in typescript.

Sorry I initially didn't search in typescript's github, I found this issue they are currently investigating: https://github.com/Microsoft/TypeScript/issues/30663

@weswigham @RyanCavanaugh Can we please look into quickly publishing a revert to the styled components types that does not have the perf issues on 3.4.

With the VS Code 1.33 release, a lot of js users are going to be downloading the bugged types through automatic type acquisition. Once this happens, to get out of the bad state, I believe that you either have to clear your automatic type acquisition cache or install the fixed @types/styled-components. Neither are good experiences for js users. The longer the poorly performing typings are the latest published version the more users who are going to be effected (which is a bad experience for them and lots of extra work for us too)

This seems like it may still be an issue with @types/styled-components 4.1.19 and TS 3.6.3. TS completion and error highlighting taking 5-10+ seconds on 2018 i7 macbook pro 15. Need to do some more investigation.

Erm, the OP is talking about 90s compilations (a 9x jump in time form the prior styled components version), seeing as both later version of TS have mitigations in place and later version of styled components were simplified to not have so much of a perf issues, 5-10s is maybe just your project and deps behaving normally.

I hope not! It's frustratingly slow now when it wasn't in the past. I'm going to look into it further and report back here if it appears to be related to this issue.

My VSCde is unusable (ts errors appear and disappear after few seconds instead of instantly) as soon as I add @types/styled-components.

I'm using TS 3.6.4 and types 4.1.20.

@sregg go blame this PR that reverted the mitigation in @types/styled-components: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323

(And roll back to v 4.1.19 to fix the issue locally)

@sregg go blame this PR that reverted the mitigation in @types/styled-components: #39323

@typescript-bot gathers performance metrics to “gauge whether [PRs] might negatively affect compile times or editor responsiveness”. In PR 39323, @typescript-bot concluded “It looks like nothing changed too much.”.

@sregg, can you think of a reason why @typescript-bot’s existing metrics would fail to highlight the editor performance issue you observe?

(Sidebar: “go blame this PR” is not a constructive suggestion, @weswigham. Please be constructive.)

Here’s some additional context:

@sregg has reported poor performance while using TypeScript 3.6.4: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/34391#issuecomment-548701239

But from @weswigham’s reply in https://github.com/microsoft/TypeScript/issues/30663#issuecomment-507406245, I understood that TypeScript versions ≥3.5 would no longer incur the performance penalty that https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34499 was merged to avoid.

So, with that understanding, I opted to (more-or-less) revert https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34499, via https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323.

The bot's perf metrics are based on what's in the tests and, unfortunately, the styled components tests are pretty far from a real app, both in size and (complex) usage. It's doing the best it can with what it's got, however it doesn't always find _every_ perf issue.

(Sidebar: "blame" in the "git" sense - please don't take offense~)

That makes sense, thanks @weswigham!

Until we can catch this performance regression in tests, I think the best course of action is to revert PR https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323, so I’ve opened PR https://github.com/DefinitelyTyped/DefinitelyTyped/pull/40095 to do so.

Next week, I’ll work to add a test based on the reports (e.g. https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323#issuecomment-549015652) that were shared. Once that’s working, we can (ex ante) evaluate other solutions similar to https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323.

@smockle have you tried running the latest version (4.4.2)? Seems like the performance bug is back again, downgrading to 4.1.19 helps.


UPD: Same with s-c typings v5.0.1

@sregg
Me too!!!

My VSCode(*Actually TS-SERVER) is slower than before. after using styled-components.
"@types/styled-components": "^5.1.0", "styled-components": "^5.1.1" "typescript": "^3.9.5"

After downgrading TS from 3.9.X to 3.8.3 performance went back to normal again for me. Using "@types/styled-components": "^5.1.0" and "styled-components": "^5.1.1".

Thanks @joaopaulobdac, I have been working on one project that is substantially slower at typescript evaluation than the other, and it took me so long to realize Styled Components was the culprit. Your fix got'r done for me. Didn't seem to be using any of the 3.9x features of typescript so it was a pretty painless switch!

Should we create a new issue then? Not upgrading is only a short-term solution.

I am experiencing the same problem with latest June 2020 (version 1.47) and "@types/styled-components": "^5.1.1"

Using typescript 3.9.3 with the styled-components types version 5.1.1 absolutely destroys my VSCode TS server performance. It is absolutely unusable :D Downgrading to typescript 3.8.3 seems to restore at least some of the performance, but this indeed could use some more attention.

@RyanCavanaugh reopen?

Can confirm, experiencing the same issue.

Same here, worth reopening!

I confirm that my VSCode has started to choke.

I ended up removing styled-components, it didn't provide a ton of benefit on react-native for us anyway. Plain old JS objects with spread operator and inline styles works great with no TS perf issues, IMO ends up being easier to read code than with styled-components anyway at least on RN.

I'm experiencing the hell in the CSS-in-JS haven when I am coding with VSCode.

@AndrewMorsillo @hilezir I switched from styled-components to styletron, using TS 4. Performance in styletron is much better both in vscode and in the browser. But I don't know about styletron on React Native.

@AndrewMorsillo @hilezir I switched from styled-components to styletron, using TS 4. Performance in styletron is much better both in vscode and in the browser. But I don't know about styletron on React Native.

Is too late for us to make this change but I haven't heard of styletron and definitely like the looks of it more than styled components.

Will there be a new issue or will this issue be reopened? There are still great performance issues with @types/styled-components 5.1.2 and TS 3.9.7

Spent a whole day trying to figure out how to speed up VSCode and _finally_ figured out it was @types/styled-components. When that's installed, just typing anything in the editor would cause tsserver.js (as shown via VSCode Process Explorer) to spike >100% CPU and grow unbounded in memory. Simply removing @types/styled-components fixed this.

I was using TypeScript 4.0.3 and @types/styled-components 5.1.3.

can someone suggest a better alternative to styled-components. my vscode completely freezes.

can someone suggest a better alternative to styled-components. my vscode completely freezes.

try this?

  1. https://material-ui.com/styles/basics/#material-ui-styles

  2. https://emotion.sh/docs/styled#styling-elements-and-components

There is actually a Pull Request open to improve styled-components' types performance: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/46510.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

demisx picture demisx  ·  3Comments

JudeAlquiza picture JudeAlquiza  ·  3Comments

csharpner picture csharpner  ·  3Comments

alisabzevari picture alisabzevari  ·  3Comments

JWT
svipas picture svipas  ·  3Comments