React-scripts/fork-ts-checker-webpack-plugin constant high CPU usage when using material/icons

[CloneXpert]

Is this a bug report?

Yes

Did you try recovering your dependencies?

Yes.

Which terms did you search for in User Guide?

fork-ts-checker-webpack-plugin and react-scripts combined with:
slow
stuck
cpu 100%
cpu pegged

Environment

npx: installed 1 in 2.147s
Path must be a string. Received undefined
C:\Users\Tamas\AppData\Roaming\npm\node_modules\create-react-app\index.js

Environment:
OS: Windows 10
Node: 8.11.4
Yarn: Not Found
npm: 5.6.0
Watchman: Not Found
Xcode: N/A
Android Studio: Not Found

Packages: (wanted => installed)
react: ^16.8.1 => 16.8.6
react-dom: ^16.8.1 => 16.8.6
react-scripts: 2.1.8 => 2.1.8

Steps to Reproduce

1. Install @material/icons
2. import { AccessAlarm } from "@material-ui/icons"; in App.tsx
3. 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)

Importing an icon in the wrong way (https://www.npmjs.com/package/@material-ui/icons) completely kills the node process.

Reproducible Demo

Demo:
https://stackblitz.com/edit/react-gv75il

A more illustrative way to see this happening is by trying it out locally. Then monitor the cpu usage of the fork-ts-checker-webpack-plugin.

[dmcneil]

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...

OS: Mac OSX 10.13.6 (High Sierra)
NodeJS: v10.15.3
npm: 6.4.1
create-react-app: 2.1.8
yarn: 1.15.2

package.json dependencies...

"dependencies": {
    "@material-ui/core": "^3.9.3",
    "@material-ui/icons": "^3.0.2",
    "@types/jest": "24.0.11",
    "@types/node": "11.13.0",
    "@types/react": "16.8.12",
    "@types/react-dom": "16.8.3",
    "axios": "^0.18.0",
    "react": "^16.8.6",
    "react-dom": "^16.8.6",
    "react-scripts": "2.1.8",
    "typescript": "3.4.2"
  }

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.

[CloneXpert]

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]

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 [email protected] should do the trick.

[ianschmitz]

@CloneXpert were you able to try an older version of TypeScript to confirm?

[CloneXpert]

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]

Having same issue as @CloneXpert

[ianschmitz]

/cc @johnnyreilly have you seen this before?

[johnnyreilly]

Haven't experienced it myself - I've heard about memory issues with a recent release of TypeScript; possibly related.

[pedromarquesm]

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]

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]

@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]

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]

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

[delaaxe]

I confirm the fix works like a charm

[CloneXpert]

Thanks, can confirm too that the setting fixes it.

[johnnyreilly]

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!

[devmartinez0]

@johnnyreilly's solution woked for me. THANKS!! *crying*

[delaaxe]

Seems like updating to Typescript 3.5 improved the situation

[stale]

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]

Also still have this issue, but the fix did work!

[stale]

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]

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.