verifying what backend is being used by watcher

[snoolord]

Hi team,

I am considering switching from chokidar to watcher but need to be able to verify what backend watcher is using.
I have had issues where my final electron build ends up falling back to polling with chokidar, so I want to make sure that watcher is utilizing fs-events.

It is not immediately clear to me how to verify that watcher is using "fs-events" or if it is using the fallback.

Any help would be greatly appreciated! 🙇

Thanks

[bpasero]

You can explicitly pass the backend to use as options: https://github.com/parcel-bundler/watcher?tab=readme-ov-file#options

I am not aware that the watcher would fallback, I am not even sure what the fallback would be for macOS?

[snoolord]

thanks for the response @bpasero, I think the fallback will be 'brute-force', but I'm not sure how to verify that the backend is being used. Maybe there is an error message that watcher uses the fallback, but i
I want to build my app in production and have a log to verify.

in chokidar, i do something like this

    chokidar.on('ready', () => {
      if (chokidar.platform === 'darwin' && chokidar.options.useFsEvents === false) {
        log(
          'The chokidar process falls back to polling. This may lead to a high CPU usage.'
        )
      } else if (chokidar.platform === 'darwin' && chokidar.options.useFsEvents === true) {
       log(
           The chokidar process utilizes fsevents. File changes are detected without polling.'
        )
      }
    })

just wary as I have improperly bundled fs-events into my electron build and the production build chokidar was not using fs-events.

[bpasero]

I am quite certain that parcel watcher would use fsevents on macOS and ReadDirectoryChangesW on Windows. This module does not depend on the NPM module that you refer to at all.

[rogerweb]

It does. And it will use kqueue if FSEvents is not available. This is in the README.md, but the point is: how the application can tell in runtime which one the watcher is using?

[bpasero]

Ok, now I am curious as well. I was not aware that fsevents would not be available on macOS (unless maybe very old macOS versions). And looking at the sources its not very obvious to me how at all Kqueue would be used as fallback.

[mischnic]

This function gets called with either a concrete (set via options) backend or with default:

watcher/src/Backend.cc

Line 26 in 8dfd994

std::shared_ptr<Backend> getBackend(std::string backend) {

All of these availability checks (apart from watchman) are really compile time checks, so it depends on what you compile for/against. Not really what is available at runtime (apart from watchman)

Fore example, I think it will only use kqueue by default on FreeBSD. And never on macOS because fsevents is always available there and takes priority.

[snoolord]

this may be only an issue when it comes to electron because it is all packaged. I ran into this issue outlined by the blog in https://www.hendrik-erz.de/post/electron-chokidar-and-native-nodejs-modules-a-horror-story-from-integration-hell.
when electron is packaged, fs-events is not included and chokidar cannot use it.
maybe parcel does not have this issue because it is compiled from C++.

Nonetheless, it would be nice to be able to verify the backend at runtime.
e.g. electron app installs watchman onto the user's system and uses parcel/watcher to watch the filesystem. would be nice to have a way to verify that it is indeed using watchman for linux/windows.

I have 0 knowledge of C++, so I am unsure of the complexity of adding this functionality.

[mischnic]

Correct. Parcel doesn't use fsevents (the npm package), but fsevents (the C API).

[c5n8]

I found this in the log of docker compose watch

Syncing "directory" after changes were detected:
  - directory/.watchman-cookie-f8c2f2f04170-217-0

So, I suppose if you detect some files like this, then watchman is used as backend.

Reference: facebook.github.io/watchman/docs/cookies