Suggestion

🔍 Search Terms

idle watch watcher cpu chokidar

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.
  Would actually further goal 10, cross-platform development

⭐ Suggestion

Please add one or more of these:

• chokidar as a new option for tsconfig::watchOptions.watchFile and tsconfig::watchOptions.watchDirectory
• chokidar as a new option for env::TSC_WATCHFILE and env::TSC_WATCHDIRECTORY
• chokidar as default watcher – maybe dependent on whether chokidar is available in the project

💻 Use Cases

While working with create-react-app, I noticed that my machine tended to get quite loud. Investigating that, I found the reason to be surprisingly large CPU utilization. That, in turn, I could trace back to this issue:
TypeStrong/fork-ts-checker-webpack-plugin#236

The solution there was to switch TSC to fs.watch instead of fs.watchFile. That works for the most part. However, as Sheetal Nandi (@sheetalkamat) points out in #31048 (comment), that implementation is known to be problematic. Which is why it is not the default and won't be in the foreseeable future.

Prior discussions

#31048 talks about the background to this request. There, Nico Burns (@nicoburns) already asked about this:

Would you consider switching to Chokidar? It's a battle tested solution used very widely throughout the Node ecosystem. We're in the process of switching to TypeScript at work, and the watch processes are taking ~45% cpu each on my 2015 MacBook Pro. As far as I am aware Node's built-in file watching capabilities are generally considered broken and not suitable for production use.

In response, Jason Williams (@jasonwilliams) pointed out that webpack had switched back to fs.watch, which might indicate that it had been fixed by now. Unfortunately, node v16 still has the same warnings, and webpack's switch seems to have been less thoroughly investigated than we would have desired: webpack/watchpack#130

#19762 and #17506 also showed performance issues. #19762 actually has the same resolution as TypeStrong/fork-ts-checker-webpack-plugin#236, and #17506 seems to have prompted some intensive work.