You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[@types/styled-components] Performance issues on compiler #34391
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 tsc@3.4.1.
By using this seed repo, I've tested the following versions:
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.
I tried using the @types/xxxx package and had problems.
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/styled-components@4.1.12 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.
Reacted by Beau Smith, Iago Belo and Prabhu Murthy
@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:
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:
@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.
@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)
Reacted by Janosh Riebesell, tnx247, Michał Lytek, Eduardo Merino, Thomas Daniellou, Pavel Udaloff, Amit Bansal and Leonardo E. Dominguez
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 intelisense is extremally slow when using the 5.1.9 version. Errors were taking over 10 seconds to show up and the intelisense was taking over 5 seconds.
The issue disappeared when downgrading to 4.0.3 version. Not the best solution but worked for me.
Reacted by Nate Moore, Cherik, sicko and Mike Davies
My intelisense is extremally slow when using the 5.1.9 version. Errors were taking over 10 seconds to show up and the intelisense was taking over 5 seconds.
The issue disappeared when downgrading to 4.0.3 version. Not the best solution but worked for me.
I am still experiencing very slow type checks with tsserver 😢
I compared on the following component :
<Titlevariant="header">Hello</Title>
If I remove the e from "header", it becomes "hader" with is a type error. But my editor takes 10 seconds to show it to me! If I try to autocomplete, it takes like ~5 seconds.
I tried to switch to emotion and did the same experiment... It takes less than 1 second for both type check and autocompletion to work!
I asked some colleagues and they had the same issue on other projects. Any idea?
Do you find emotion has a similar / replaceable API with styled-components? I am working on getting our compilation speeds back up to snuff only to realize I think this is the only issue.
Well, the migration is quite easy. It depends on the size of your project, but it's mostly replacing imports from styled-components to emotion.
You'll have some stuff changing, some slight differences in the API, but it should be mostly working. I'd suggest to give it a try!
On react-native, there is an annoying problem with emotion though (but it has a solution).
Which does exactly the same but won't cause any issue to emotion.
The annoying thing with this problem is that it's silent, so you need to carefully check. If you use styled components this way, I'd suggest to search for }px in your project.
In case it helps anyone, I solved my own problem by creating my own type definitions for Styled Components. It was intended to be a temporary fix but ended up doing everything I needed. If you'd like to use it, just remove your dependency on @types/styled-components and drop in this file (and reference it in your tsconfig): https://gist.github.com/nfarina/ea282fbb01574e95d87ce661f7fe8630
I just define the element types I actually use and add them as necessary. I'm never going to do styled.audio, for example, so there's no need to have it in there contributing to the slowness.
It makes a noticeable and worthwhile difference and I haven't needed to sacrifice any typing capabilities.
@djskinner Do you have the steps to achieve the replacements?
Did you have to clone the entire styled-components typings in your source code or did you find a way to override its usage in @types/styled-components?
I created a file called styled-components-fast.ts and changed all imports to use this file instead:
- import styled from 'styled-components'+ import styled from 'styled-components-fast'
Note: the way the project is set up with webpack module resolution allows for this type of absolute import. You may need to do something like import styled from './styled-components-fast' depending on your setup.
styled-components-fast.ts mostly just re-exports types and implementations from styled-components but anywhere any type refers to JSX.IntrinsicElements either explicitly or implicitly then the type is copied into this file and changed to refer to JSXIntrinsicElementsMinimal, instead of direct re-exporting. It looks like this currently: https://gist.github.com/djskinner/515d96af8d8b59bd6304bcddd7a26bc6
Note:
I have only re-exported the things currently being used so you may need to re-export more stuff as necessary
I think I removed some deprecated APIs from some of the modified types
You should update the JSXIntrinsicElementsMinimal union to only include the elements you use with styled for the best performance
Activity
eps1lon commentedon Apr 3, 2019
Does this also happen with typescript 3.3?
DylanJu commentedon Apr 3, 2019
I experienced same issue
package.json
devDependency
dependency
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/styled-components@4.1.12 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.
michsa commentedon Apr 3, 2019
@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:And here are both of the places
OmitUis used inindex.d.ts:Definition of
WithOptionalThemeUsage of
WithOptionalTheme(in the definition ofStyledComponentProps)Something about the union-distributed
OmitUmapping over anotherOmitUseems to be tripping up the compiler. If either or both of these instances is replaced with a regularOmitthat 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
ReactDefaultizedPropstype also referencesPickU, 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:Here is
time yarn tscrun against typescript 3.4.1, 3.4.0-dev.20190226, and the immediate prior release, 3.4.0-dev.20190223:WithOptionalThemedefinitionWithOptionalThemeusageOmitUOmitUOmitUOmitPickUOmitPickUOmitUOmitPickUOmitPickUOmitUOmitOmitOmitUOmitPickUOmitOmitOmitPickUOmitOmitRunning 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!
flut1 commentedon Apr 3, 2019
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
eps1lon commentedon Apr 3, 2019
@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.
voliva commentedon Apr 3, 2019
Sorry I initially didn't search in typescript's github, I found this issue they are currently investigating: microsoft/TypeScript#30663
mjbvz commentedon Apr 5, 2019
@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)evelant commentedon Sep 11, 2019
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.
weswigham commentedon Sep 11, 2019
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.
evelant commentedon Sep 11, 2019
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.
sregg commentedon Nov 1, 2019
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.
weswigham commentedon Nov 1, 2019
@sregg go blame this PR that reverted the mitigation in
@types/styled-components: #39323weswigham commentedon Nov 1, 2019
(And roll back to v
4.1.19to fix the issue locally)smockle commentedon Nov 2, 2019
@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.)
28 remaining items
Adryel123 commentedon Jul 27, 2021
My intelisense is extremally slow when using the 5.1.9 version. Errors were taking over 10 seconds to show up and the intelisense was taking over 5 seconds.
The issue disappeared when downgrading to 4.0.3 version. Not the best solution but worked for me.
pierpo commentedon Sep 21, 2021
We should identify what's changed, then!
Also, we could take inspiration from emotion's types. They work really well, and the API is the same.
googidaddy commentedon Oct 26, 2021
same 2!!!
Andrew1431 commentedon Oct 26, 2021
Why is this issue closed? Everyone seems to be having this issue.
Andrew1431 commentedon Oct 26, 2021
Do you find emotion has a similar / replaceable API with styled-components? I am working on getting our compilation speeds back up to snuff only to realize I think this is the only issue.
pierpo commentedon Oct 26, 2021
Well, the migration is quite easy. It depends on the size of your project, but it's mostly replacing imports from styled-components to emotion.
You'll have some stuff changing, some slight differences in the API, but it should be mostly working. I'd suggest to give it a try!
On react-native, there is an annoying problem with emotion though (but it has a solution).
This doesn't work anymore :
because emotion doesn't convert numbers to string properly inside template strings.
You need to replace it with this :
Which does exactly the same but won't cause any issue to emotion.
The annoying thing with this problem is that it's silent, so you need to carefully check. If you use styled components this way, I'd suggest to search for
}pxin your project.nfarina commentedon Oct 26, 2021
In case it helps anyone, I solved my own problem by creating my own type definitions for Styled Components. It was intended to be a temporary fix but ended up doing everything I needed. If you'd like to use it, just remove your dependency on
@types/styled-componentsand drop in this file (and reference it in yourtsconfig): https://gist.github.com/nfarina/ea282fbb01574e95d87ce661f7fe8630googidaddy commentedon Oct 27, 2021
TSSERVER broken in 5.1.15!!!!!!!!!!!!!!!!!
Foxhoundn commentedon Nov 1, 2021
A little bump here - removing
@types/styled-components5.1.15 fixed a lot of perfomance issues in my VSCode.emiomacollins commentedon May 30, 2022
Hi Everyone I've been having this issue for a while now. Downgrading @types/styled-components worked for me.
yarn add @types/styled-components@4.0.3
lin2006yuo commentedon Jul 23, 2022
@types/styled-components5.1.25 still slow🙁djskinner commentedon Aug 24, 2022
I have discovered that, for us at least, a lot of the performance issues stem from the types deriving massive unions of all the valid JSX elements. Such large unions can be a performance issue as described here: https://github.com/microsoft/TypeScript/wiki/Performance#preferring-base-types-over-unions
So I created custom types that replace usages of
JSX.IntrinsicElementswithJSXIntrinsicElementsMinimal:I just define the element types I actually use and add them as necessary. I'm never going to do
styled.audio, for example, so there's no need to have it in there contributing to the slowness.It makes a noticeable and worthwhile difference and I haven't needed to sacrifice any typing capabilities.
yleflour commentedon Sep 30, 2022
@djskinner Do you have the steps to achieve the replacements?
Did you have to clone the entire styled-components typings in your source code or did you find a way to override its usage in @types/styled-components?
djskinner commentedon Sep 30, 2022
I created a file called
styled-components-fast.tsand changed all imports to use this file instead:Note: the way the project is set up with webpack module resolution allows for this type of absolute import. You may need to do something like
import styled from './styled-components-fast'depending on your setup.styled-components-fast.tsmostly just re-exports types and implementations fromstyled-componentsbut anywhere any type refers toJSX.IntrinsicElementseither explicitly or implicitly then the type is copied into this file and changed to refer toJSXIntrinsicElementsMinimal, instead of direct re-exporting. It looks like this currently: https://gist.github.com/djskinner/515d96af8d8b59bd6304bcddd7a26bc6Note:
JSXIntrinsicElementsMinimalunion to only include the elements you use withstyledfor the best performancevavra7 commentedon Oct 28, 2022
Please open this. Still a big problem...