If you have the driver for the iDP SMART-31S printer (and likely other models from the same company) installed on your Windows system, then parcel watcher does not work.
Why does this happen?
The iDP printer driver installs an executable called Watchman.exe into C:\Windows\System32\Watchman.exe.
The purpose of this executable looks to be a background service that continiously watches connected iDP printers for status errors like the card being jammed and then notifying either other software or the user about this.
When @parcel/watch checks to see if Facebook's watchman service is available it calls WatchmanBackend::checkAvailable which calls watchmanConnect which calls getSockPath which finally then calls popen("watchman --output-encoding=bser get-sockname", "r");. This spawns the iDP "watchman" printer service because system32 is in the %PATH% environment variable on Windows:
This process never returns as it's supposed to be a background service for telling you the printer is jammed, so parcel watch dutifully hangs forever waiting for it to return a socket path.
Discussion
I'm not sure what there is to do about this. I suppose this kind of conflict is inevitable when the process for detecting watchman being installed is spawn a process called "watchman" and hope it's the right one. Perhaps parcel could be more smart about detecting if watchman is installed by looking for other files included in Facebook's watchamn service exists alongside watchman like watchman-make and watchman-wait, or by excluding execution of watchman binaries from inside %SSystemRoot%.
A more robust solution would be to have some sort of unique signature or tell in the watchman executable/installation directory so that you can easily tell for certain that it's fb-watchman you're dealing with, and not some random other executable.
For what it's worth it looks like the fb-watchman npm package suffers from the same problem when detecting if the watchman service is present.
If you have the driver for the iDP SMART-31S printer (and likely other models from the same company) installed on your Windows system, then parcel watcher does not work.
Why does this happen?
The iDP printer driver installs an executable called
Watchman.exeintoC:\Windows\System32\Watchman.exe.The purpose of this executable looks to be a background service that continiously watches connected iDP printers for status errors like the card being jammed and then notifying either other software or the user about this.
When
@parcel/watchchecks to see if Facebook's watchman service is available it callsWatchmanBackend::checkAvailablewhich callswatchmanConnectwhich callsgetSockPathwhich finally then callspopen("watchman --output-encoding=bser get-sockname", "r");. This spawns the iDP "watchman" printer service because system32 is in the%PATH%environment variable on Windows:This process never returns as it's supposed to be a background service for telling you the printer is jammed, so parcel watch dutifully hangs forever waiting for it to return a socket path.
Discussion
I'm not sure what there is to do about this. I suppose this kind of conflict is inevitable when the process for detecting watchman being installed is spawn a process called "watchman" and hope it's the right one. Perhaps parcel could be more smart about detecting if watchman is installed by looking for other files included in Facebook's watchamn service exists alongside watchman like
watchman-makeandwatchman-wait, or by excluding execution of watchman binaries from inside%SSystemRoot%.A more robust solution would be to have some sort of unique signature or tell in the watchman executable/installation directory so that you can easily tell for certain that it's fb-watchman you're dealing with, and not some random other executable.
For what it's worth it looks like the
fb-watchmannpm package suffers from the same problem when detecting if the watchman service is present.