Skip to content

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

Closed

Description

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

Activity

  1. dmcneil commented on Apr 11, 2019

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

  2. CloneXpert commented on Apr 11, 2019

    @CloneXpert
    Author

    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.

  3. ianschmitz commented on Apr 13, 2019

    @ianschmitz
    Contributor

    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.

  4. ianschmitz commented on Apr 17, 2019

    @ianschmitz
    Contributor

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

  5. CloneXpert commented on Apr 17, 2019

    @CloneXpert
    Author

    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.

  6. delaaxe commented on Apr 17, 2019

    @delaaxe

    Having same issue as @CloneXpert

  7. ianschmitz commented on Apr 17, 2019

    @ianschmitz
    Contributor

    /cc @johnnyreilly have you seen this before?

  8. johnnyreilly commented on Apr 17, 2019

    @johnnyreilly
    Contributor

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

  9. pedromarquesm commented on Apr 18, 2019

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

  10. CloneXpert commented on Apr 18, 2019

    @CloneXpert
    Author

    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.

  11. pedromarquesm commented on Apr 18, 2019

    @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

  12. johnnyreilly commented on Apr 18, 2019

    @johnnyreilly
    Contributor

    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.

  13. johnnyreilly commented on Apr 20, 2019

    @johnnyreilly
    Contributor

    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

  14. delaaxe commented on Apr 20, 2019

    @delaaxe

    I confirm the fix works like a charm

  15. danielblair commented on Apr 22, 2019

    @danielblair
  16. CloneXpert commented on Apr 23, 2019

    @CloneXpert
    Author

    Thanks, can confirm too that the setting fixes it.

  17. johnnyreilly commented on May 25, 2019

    @johnnyreilly
    Contributor

    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!

  18. devMartinoz commented on May 30, 2019

    @devMartinoz

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

  19. delaaxe commented on May 31, 2019

    @delaaxe

    Seems like updating to Typescript 3.5 improved the situation

  20. stale commented on Jun 30, 2019

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

  21. scrawfor commented on Jul 3, 2019

    @scrawfor

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

  22. stale commented on Aug 2, 2019

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

  23. stale commented on Aug 7, 2019

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

  24. locked and limited conversation to collaborators on Aug 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions