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
React-scripts/fork-ts-checker-webpack-plugin constant high CPU usage when using material/icons #6792
import { AccessAlarm } from "@material-ui/icons"; in App.tsx
npm start
Expected Behavior
Once it has finished building, the cpu usage should become minimal.
Actual Behavior
One of the node processes, more specifically the fork-ts-checker-webpack-plugin, flips out and pushes the CPU non-stop (I left it there overnight and was still running high the day after)
I'm experiencing this exact same issue on OSX. I've noticed the CPU usage of the fork-ts-checker-webpack-plugin idling at around 70% and going even higher when the development server via yarn start is recompiling.
My project is only a handful of files but I too am using @material-ui/icons and after seeing this post, removed the module, and now the fork-ts-checker-webpack-plugin is idling at a much more reasonable 10% via htop or so. That still seems a bit high but I'm not sure what is typical for the process and it is at least 7 times better.
Just to add to the original post with some additional information since @CloneXpert is on Windows...
EDIT It looks like this may be related to how the icons (and how many) are being imported. For example, instead of importing something like:
import { Error} from '@material-ui/icons';
It should be more narrow like:
import ErrorIcon from '@material-ui/icons/Error';
I believe this is what is being described on the NPM page here. Using this approach, I'm able to reduce the CPU usage of the fork-ts-checker-webpack-plugin to the 10% or so that I mentioned above when I removed the module/icon usage altogether.
I find it very difficult to trace down what's causing this. Can anyone help with identifying what packages can cause this? I removed material icons completely and still have the same issue in my bigger application.
This is most likely related to microsoft/TypeScript#30663, and is not the fault of fork-ts-checker-webpack-plugin, but typescript itself. Pinning to typescript@3.3.x should do the trick.
Thanks for the suggestion. I did try and it was much faster as others were suggesting. However it doesn't solve the issue reported here. The fork-ts-checker-webpack-plugin still has a never ending high CPU usage. It works if I kill it, but it will respawn immediately after I save a change. I am still unable to point out what's causing it.
although new TS versions don't work properly, I found out version above 2.1.4 of 'react-scripts', cause high cpu usage and CPU temperatures pikes.
Using 2.1.3 and everything fine.
Can somebody else confirm this please?
Thanks Pedro, that's super helpful.
Downgrading to 2.1.3 does indeed work much better. CPU usage dropped almost completely. So I guess it's a matter of finding out what change may be related to this in 2.1.4. Thanks everyone for looking into this.
@CloneXpert One good feature was async type check.
Files were deployed right after compiling, and you could browse through the website while type checks were made (that usually take some seconds)
It was a really good improvement from 2.1.5+
But I don't really want a flying MacBook Pro.
Even 1 build would spike CPU temperatures and max Fans.
Got reports from other developers using macbooks, with the same issue.
Linux users don't seem affected with v2.1.8, hope this helps
See TypeStrong/fork-ts-checker-webpack-plugin#256 - we're currently mulling what the best way forward is. But for now, setting this environment variable will resolve woes by all accounts: TSC_WATCHFILE=UseFsEventsWithFallbackDynamicPolling
Reacted by delaaxe, Ian Schmitz, Eduardo Leite, Lucas Nicolas Pelloni, Jan Kalfus, InvictusMB, Cahil Foley, devMartinoz, Juan Laría, Christian Fosli and 1 more
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
Activity
dmcneil commentedon Apr 11, 2019
I'm experiencing this exact same issue on OSX. I've noticed the CPU usage of the
fork-ts-checker-webpack-pluginidling at around 70% and going even higher when the development server viayarn startis recompiling.My project is only a handful of files but I too am using
@material-ui/iconsand after seeing this post, removed the module, and now thefork-ts-checker-webpack-pluginis idling at a much more reasonable 10% via htop or so. That still seems a bit high but I'm not sure what is typical for the process and it is at least 7 times better.Just to add to the original post with some additional information since @CloneXpert is on Windows...
package.json dependencies...
EDIT It looks like this may be related to how the icons (and how many) are being imported. For example, instead of importing something like:
It should be more narrow like:
I believe this is what is being described on the NPM page here. Using this approach, I'm able to reduce the CPU usage of the
fork-ts-checker-webpack-pluginto the 10% or so that I mentioned above when I removed the module/icon usage altogether.CloneXpert commentedon Apr 11, 2019
I find it very difficult to trace down what's causing this. Can anyone help with identifying what packages can cause this? I removed material icons completely and still have the same issue in my bigger application.
ianschmitz commentedon Apr 13, 2019
This is most likely related to microsoft/TypeScript#30663, and is not the fault of
fork-ts-checker-webpack-plugin, buttypescriptitself. Pinning totypescript@3.3.xshould do the trick.ianschmitz commentedon Apr 17, 2019
@CloneXpert were you able to try an older version of TypeScript to confirm?
CloneXpert commentedon Apr 17, 2019
Thanks for the suggestion. I did try and it was much faster as others were suggesting. However it doesn't solve the issue reported here. The fork-ts-checker-webpack-plugin still has a never ending high CPU usage. It works if I kill it, but it will respawn immediately after I save a change. I am still unable to point out what's causing it.
delaaxe commentedon Apr 17, 2019
Having same issue as @CloneXpert
ianschmitz commentedon Apr 17, 2019
/cc @johnnyreilly have you seen this before?
johnnyreilly commentedon Apr 17, 2019
Haven't experienced it myself - I've heard about memory issues with a recent release of TypeScript; possibly related.
pedromarquesm commentedon Apr 18, 2019
although new TS versions don't work properly, I found out version above 2.1.4 of 'react-scripts', cause high cpu usage and CPU temperatures pikes.
Using 2.1.3 and everything fine.
Can somebody else confirm this please?
CloneXpert commentedon Apr 18, 2019
Thanks Pedro, that's super helpful.
Downgrading to 2.1.3 does indeed work much better. CPU usage dropped almost completely. So I guess it's a matter of finding out what change may be related to this in 2.1.4. Thanks everyone for looking into this.
pedromarquesm commentedon Apr 18, 2019
@CloneXpert One good feature was async type check.
Files were deployed right after compiling, and you could browse through the website while type checks were made (that usually take some seconds)
It was a really good improvement from 2.1.5+
But I don't really want a flying MacBook Pro.
Even 1 build would spike CPU temperatures and max Fans.
Got reports from other developers using macbooks, with the same issue.
Linux users don't seem affected with v2.1.8, hope this helps
johnnyreilly commentedon Apr 18, 2019
There's some suggestions here that might be worth looking into: TypeStrong/fork-ts-checker-webpack-plugin#236 (comment)
I'm open to PRs that remedy any issues.
johnnyreilly commentedon Apr 20, 2019
See TypeStrong/fork-ts-checker-webpack-plugin#256 - we're currently mulling what the best way forward is. But for now, setting this environment variable will resolve woes by all accounts:
TSC_WATCHFILE=UseFsEventsWithFallbackDynamicPollingdelaaxe commentedon Apr 20, 2019
I confirm the fix works like a charm
danielblair commentedon Apr 22, 2019
CloneXpert commentedon Apr 23, 2019
Thanks, can confirm too that the setting fixes it.
johnnyreilly commentedon May 25, 2019
To spread the knowledge about this issue (and the workaround) I've blogged it here: https://blog.johnnyreilly.com/2019/05/typescript-and-high-cpu-usage-watch.html
Hope it helps people reading this!
devMartinoz commentedon May 30, 2019
@johnnyreilly's solution woked for me. THANKS!! *crying*
delaaxe commentedon May 31, 2019
Seems like updating to Typescript 3.5 improved the situation
stale commentedon Jun 30, 2019
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
scrawfor commentedon Jul 3, 2019
Also still have this issue, but the fix did work!
stale commentedon Aug 2, 2019
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
stale commentedon Aug 7, 2019
This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.