Enable chokidar-based watch

[c-vetter]

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

[jakub-g]

Semi-related: vscode has just switched their watchers to @parcel/watcher: see discussions at
microsoft/vscode#132483 and microsoft/vscode@85c5eb7

[bpasero]

Fyi, there is now extension API in VSCode to watch files and folders, you don't have to ship your own watcher solution.

[jakebailey]

We still have the CLI watch mode and the server itself (which runs in places that are not VS Code), so we still have to have some implementation.

[bpasero]

Got it, then I can recommend https://github.com/parcel-bundler/watcher. There is one gotcha when considering: chokidar supports glob patterns for excludes, while parcel does not. This is only really important on Linux where the OS does not provide efficient recursive watching support and where file handles are limited. Reported as parcel-bundler/watcher#64

[jakebailey]

There's a few other things to consider in that TS is currently dependency free, and we use multiple types of watchers (polling versus not) for different scenarios, but parcel's watcher is certainly an improvement over the other choices from my own testing back when I was working on pyright, at the cost of having a compiled component.

[bpasero]

Given parcels snapshot support, we have built a polling watcher on top of it, even though that is not really advertised from the readme (implementation here).

Being dependency free is a very good goal to achieve, though parcel itself also comes with very few dependencies. Ideally we could just push something like parcel down to node.js core and be done with it...