Consider replacing chokidar with filespy

[aleclarson]

Is your feature request related to a problem? Please describe.
Vite could take advantage of Watchman when installed and the other benefits of using filespy, like event throttling, native performance (powered by @parcel/watcher), and more.

Disclaimer: I haven't compared chokidar and filespy in a benchmark yet. Should probably do that.

Describe the solution you'd like
Replace chokidar with filespy.

[aleclarson]

I just realized I'll have to add out-of-root watching to meet Vite's needs. I could write a wrapper package that does that by creating multiple watchers (one per root), but I'll wait for Evan's response first.

[yyx990803]

Considering replacing the watcher may introduce unknown behavior changes, I don't think it's worthwhile to replacing it unless chokidar is causing real issues - and so far it seems to be working fine. I also don't think file watching is a perf bottleneck in any known cases unless there are benchmarks showing so.

[aleclarson]

Parcel replaced Chokidar with their own C++ watcher (which is what filespy uses). For one, moving file-watching off the JS thread improves performance significantly during large sweeping changes (like a branch checkout or dependency install). Perhaps @devongovett would be willing to share more insights that motivated Parcel to move away from Chokidar.

One issue I've had with Chokidar is that it doesn't handle the renaming of directories properly. (paulmillr/chokidar#927)

Additionally, having Watchman as an optional backend should improve Vite's DX substantially.
Here's a promising quote from Scaling Mercurial at Facebook:

For our repository, enabling Watchman integration has made Mercurial’s status command more than 5x faster than Git’s status command. Other commands that look for changed files–like diff, update, and commit—also became faster.

But I agree that such a migration shouldn't be taken lightly.

Benchmarks would certainly be needed before taking on such an effort.

[dominikg]

Watchman does not follow symlinks. It knows they exist, but they show up the same as any other file in its reporting.

not sure this would work well with pnpm

[aleclarson]

@dominikg Not a problem with filespy, since each file event provides a fs.Stats object whose isSymbolicLink method can be called to determine if fs.realpath should be used to resolve the symlink (if such behavior is desired).

[devongovett]

Since I was tagged... we replaced Chokidar in Parcel mainly because we ran into a lot of issues with it especially when building large projects, both on macOS and linux. Mainly this was due to running out of file descriptors due to watching individual files, and the slow crawl over the whole filesystem that chokidar does on startup. In addition, there were stability issues where the watcher would simply stop working after a while. This could have improved in the last couple years though, not sure.

That said, the main reason we wrote our own module wasn't actually for watching but for caching. Parcel's watcher can be used to efficiently detect changes in files even after a restart, which makes it work almost like watch mode after a restart. Not sure if this is a problem vite has though.