Potential CPU usage issues with typescript/eslint

[adamlindqvist]

I've noticed that since after I enabled this plugin, the CPU usage of the node process went up to 100% and my fans started to go crazy.

The node CPU usage starts to increase after a few compilation/checks.

// vite.config.js
import reactRefresh from '@vitejs/plugin-react-refresh';
import { defineConfig } from 'vite';
import checker from 'vite-plugin-checker';

export default defineConfig({
    build: {
        outDir: 'build',
    },
    server: {
        open: true,
        proxy: {
            '/api': {
                target: 'http://localhost:5000',
                changeOrigin: true,
            },
        },
    },
    plugins: [
        reactRefresh(),
        checker({
            typescript: true,
            eslint: {
                files: ['./src'],
                extensions: ['.ts', '.tsx'],
            },
        }),
    ],
});

  System:
    OS: macOS 11.5.2
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 2.05 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.16.1 - /usr/local/bin/node
    npm: 6.14.14 - /usr/local/bin/npm
  Browsers:
    Chrome: 92.0.4515.159
    Firefox: 90.0.2
    Safari: 14.1.2
  npmPackages:
    vite-plugin-checker: ^0.3.4 => 0.3.4

I have problems to identify the issue any further. This is the behaviour if I have this plugin enabled. So I'm afraid I cant put any more details to it. I'm mostly creating this issue to see if there's anyone else experiencing the same issue?

[yannxaver]

+1 here. node process running at 99.9% pushing MBA M1 to 70-80 degrees. Solved when deactivating the plugin.

[franzosterkamp]

• 1 we needed to delete this plugin because of this issue, any solution out there ?

[fmendez89]

I have this issue too, I had to disable meanwhile. It literally kicked the fans of the laptop at 100%.

[DrJume]

Same here on Intel iMac running macOS 12.1, node v16.13.1, only when

{
  eslint: {
    ...
  }
}

is used in the configuration of vite-plugin-checker

[eyalw]

+1 node process at 20% CPU always.
Disabling plugin eliminates the issue

can downgrading versions help?

[fi3ework]

Sorry for the late response. Could anybody provide a minimal reproduction repository?

[fi3ework]

Same here on Intel iMac running macOS 12.1, node v16.13.1, only when

{
  eslint: {
    ...
  }
}

is used in the configuration of vite-plugin-checker

I guses maybe this is related to some wrong internal ESLint configuration inside the checker.

[LukasMarx]

We are facing the same issue. I tried to create a minimal reproduction repository today without any success. @fi3ework If you have any suggestions what could be causing this issue I would be happy to try to reproduce the issue.

Regarding your suspicion that this issue could be related to eslint, I have to say that we are not using eslint with typechecker:

{
 plugins: [
      mkcert(),
      PkgConfig(),
      OptimizationPersist(),
      Checker({ typescript: true}),
      react(),
      tsconfigPaths(),
    ]
}

However we do use eslint separately in this project, just not with this plugin.

[fi3ework]

@LukasMarx Would you like to give it a try to upgrade to 0.4.0 if you are using 0.3.x? Many bugs are fixed in 0.4.0 and I don't know whether this is also fixed as I can't reproduce it till now 😔

[fi3ework]

@LukasMarx could you use top or htop to inspect the process path

[fi3ework]

@LukasMarx You can take a look at my minimal test example: https://github.com/fi3ework/vite-plugin-checker/tree/main/playground/react-ts. And provide the information you suspect such as customized tsconfig, monorepo etc. and I would like to reproduce on my machine.

[LukasMarx]

@fi3ework

• I did update to 0.4.0 and it did not resolve the issue.
• I`m on Windows 10. The process causing the CPU-usage is "C:\Program Files\nodejs", which does not help at all...
• We are not using any config other than Checker({ typescript: true})
• Yes we are using a monorepo with lerna
• We are using @mui/material which is known for poor typescript performance. I had no luck reproducing the issue by importing a mui component though.
• We are using paths alias in our tsconfig. Removing these in the reproduceable setup did result in a Typescript error (obviusly) but did not reduce CPU usage when idle.
• We are using eslint with an .eslintrc.json file at the root of the monorepo
• Our project is medium to large in size with lots of dependencies.

Here is our tsconfig.json

{
  "compilerOptions": {
    "target": "ESNext",
    "lib": ["dom", "dom.iterable", "esnext"],
    "baseUrl": ".",
    "paths": {
      "translations/*": ["./src/translations/*"],
      "shared": ["./src/shared/index.ts"],
      "config/*": ["./src/config/*"],
      "shared/*": ["./src/shared/*"],
      },
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "experimentalDecorators": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",
    "noImplicitAny": false
  },
  "include": ["src", "jest.config.ts", "src/Cypress.d.ts"],
  "exclude": ["node_modules", "assets", "out", "build"]
}

And here is the vite.config.ts:

import { defineConfig } from "vite";
import tsconfigPaths from "vite-tsconfig-paths";
import Checker from "vite-plugin-checker";
import OptimizationPersist from "vite-plugin-optimize-persist";
import PkgConfig from "vite-plugin-package-config";
import mkcert from "vite-plugin-mkcert";
import react from "@vitejs/plugin-react";

export default defineConfig(({ mode }) => {
  return {
    optimizeDeps: {
      include: ["react-grid-layout", "@mui/material"],
    },
    base: "./",
    build: {
      outDir: "build",
      reportCompressedSize: false,
      sourcemap: true,
    },
    plugins: [
      mkcert(),
      PkgConfig(),
      OptimizationPersist(),
      Checker({ typescript: true }),
      react(),
      tsconfigPaths(),
    ],
    resolve: {
      alias: {
        "react/jsx-runtime":
          "../../node_modules/react/cjs/react-jsx-runtime.production.min.js",
      },
    },
    json: {
      namedExports: false,
      stringify: true,
    },
    server: {
      https: true,
    },
    define: {
      "process.env": {},
    },
  };
});

Let me know if you need more information. I will try to come up with more ideas and reproduce this issue. Thank you for your help!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a bug report, please provide a minimal re-production repository or use path to reproduce. Thank you for your contributions.

[fi3ework]

not stale

[raszi]

This is still an issue, it does exist even in the newest version.

[raszi]

This is still an issue, it does exist even in the newest version.

The issue is probably not in this plugin since disabling the TypeScript support solves the problem and running tsc --watch result in the same high CPU usage.

[raszi]

The issue is probably not in this plugin since disabling the TypeScript support solves the problem and running tsc --watch result in the same high CPU usage.

Also following this guide and changing how tsc checks for changes solves the problem.

TLDR: Adding an env variable TSC_WATCHFILE=UseFsEventsWithFallbackDynamicPolling solves the problem.

[fi3ework]

update

I think UseFsEventsWithFallbackDynamicPolling works good at some most time with a low CPU load. But it also has some downside otherwise it has been set as the default strategy by tsc itself (see discussions in microsoft/TypeScript#31048). I think we can:

1. document the UseFsEventsWithFallbackDynamicPolling flag to satisfy the most common scenario.
2. fork-ts-webpack-plugin uses a custom watcher based on chokidar which implements ts.System interface. I think this is a better and long-term solution.

---

@raszi Nice catch. Maybe it should be added to the worker env by default for the typescript checker.

[mrmerc]

@fi3ework I experience the same issue, but with this configuration

checker({
  vueTsc: {
    tsconfigPath: 'tsconfig.app.json',
  },
}),

This watcher creation takes about 40s and watcher itself consumues a lot of CPU resources on each HMR update