"yarn dev:watch" uses 100% cpu when watching/idling on Windows

[jr01]

slickgrid-universal is a monorepo using lerna and when running yarn dev:watch spawns many node.js processes and on my Windows system a lot of them use 4-5% CPU just watching/polling the file system for changes.

That prohibits effective coding, makes Cypress tests time out, etc.

I found this: https://cmdcolin.github.io/2021-09-05-typescript.html and just setting environment variable TSC_WATCHFILE = 'UseFsEvents' makes all node.js processes go to 0-0.3% 😄

I don't think that would be good to do for all platforms by default. But perhaps document in README.md?

[ghiscoding]

That's a good finding, I wouldn't mind having a PR for that. The reason I use watch is because the way WebPack is currently setup with the monorepo dev seems to be using the commonJS (tsc build) instead of the ESM (regular TS), I know that d.ts typing files are for sure using the output of the build, so without the watch then I guess the whole project would fail.

in which occasion would that be a bad idea to use? If it's just an issue on VM then I don't care much and yes a note in readme might be enough. Does this flag rebuild with tsc after a file is changed? There aren't that many people contributing anyway, unfortunately, so I don't think that will have much of an impact. I'm also on Windows and I do see lots of NodeJS threads, I never realized it was because of this and the more I add new packages then the more that would consume threads, I'd be ok with this fix if I can speedup development a lot.

Side note, CI/CD GitHub Actions doesn't use dev watch to run, it instead run a WebPack prod build and that is what's then use to run Cypress tests.

Another side note, I switched from ts-loader to esbuild-loader in this PR #560 last month but I might revert that, once in a while I see the loader throws an error but all NodeJS threads are left open and I have to go and kill them all 1 by 1 in Task Manager and it's kind of annoying. The speed gain from the loader doesn't seem to be that much in real life anyway.

[jr01]

After reading this more thoroughly https://github.com/microsoft/TypeScript-Handbook/blob/master/pages/Configuring%20Watch.md#configuring-file-watching-using-environment-variable-tsc_watchfile and learning you are also on Windows I think we could just do this:

"dev:watch": "cross-env TSC_WATCHFILE=UseFsEventsWithFallbackDynamicPolling lerna run dev:watch --parallel",

About esbuild-loader : I'm not sure if I have seen left open threads/processes. I'm using a terminal from vs code to run the watch and closing the terminal kills all nodejs processes.

[ghiscoding]

Give that a try, I'll be happy with a PR if it helps a lot to free resources.
As for esbuild-loader what I meant is crashing, it seems to crash more with this loader and once it crashes then I have to kill all threads 1 by 1. It happens every once in a while, not too often but when it does it takes time to kill all NodeJS left open