Potential CPU usage issues with typescript/eslint

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?

[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!

[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 https://github.com/microsoft/TypeScript/issues/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.