Make fs.watch recursive actually useful

[paulmillr]

0.11 adds support for recursive fs watcing with fsevents.

This is great, except that even with the change fs.watch is useless crap as it was before. There are just two events that are triggered randomly: change and rename (even for deletion / creation)

Can we make it more useful at least when it's in fsevents mode?

FSEvents callback should return flags (FSEventStreamEventFlags) property. Flags are super useful — we can tell all sorts of things by them. Whether it was created, modified, deleted, whether it was a file or dir or a symlink, whether it was renamed or its finder attr was changed. Like this:

function getFileType(flags) {
  if (kFSEventStreamEventFlagItemIsFile & flags) return 'file';
  if (kFSEventStreamEventFlagItemIsDir & flags) return 'directory';
  if (kFSEventStreamEventFlagItemIsSymlink & flags) return 'symlink';
}

So, tl;dr: Introduce flags integer argument that is returned when watching through fs.watch

[indutny]

I believe that this is how it is now because this mode of operation it isn't supported on other platforms. Also, as far as I remember, FSEvents seems to be mixing flags altogether: Created | Modified | ... .

Anyway, how do you imagine this working on linux, smartos?

[paulmillr]

recursive fs.watch does not work on linux or smartos. there is no need to keep old 1arg API here. we can safely return flags as a second argument. or something

[indutny]

I'm not really sure, it may add even more diversity. @tjfontaine do you have any thoughts on it?

[paulmillr]

Just in case, the use case here is universal file watcher paulmillr/chokidar — i'm already watching stuff via node-FSEvents module, but it is horrible on windows and linux.

I include it as optionalDependency and of course it throws a GYP build error on win / linux — which is not nice for users, they think this is a real error.

Any way to access fsevents without GYP would be nice

[indutny]

I'll assign it to me, but note that it'll have low priority for me, since I have a lot of other important things to do before it.

[jorangreef]

It seems the Brackets team were able to get recursive events on Windows: adobe/brackets#6551

"This new node-module replaces Brackets' previous use of node's fs.watch() with a Windows-native implementation of the same ReadDirectoryChangesW() function, but leveraging the 'recursive' flag. So, on Windows, we now only have to set a single watcher at the project root level, rather than having to iterate thru and set individual fs.watch() watchers for each subfolder within the project. As a result, the observed "in-use" issues disappear."

[trevnorris]

@indutny The fixing patch is adobe/brackets#6686. Think we could take advantage of that code?

[indutny]

cc @saghul

[jasnell]

@indutny @trevnorris ... was there ever any resolution on this one?

[paulmillr]

@jasnell I don't think there was any resolution. They'd mention it in changelog. The way to do this now is to stick to 3rd party file watchers — chokidar etc.

[jorangreef]

@jasnell There is actually a pull request which has been waiting in libuv to add full recursive support to Windows. It needs a few tweaks and review. It would be great if this could be finished.

Recursive support is especially needed on Windows as the watch locks the watched directory (i.e. it's not possible to setup a tree of watches).

With recursive support on Mac and Windows, it will finally be possible to build a much better third party watch module (using a tree of watches for Linux + increasing the system watch limit). Most of the modules currently rely on scanning and this requires keeping the whole watched tree in memory.

[jorangreef]

libuv/libuv#198

[jasnell]

Ok, going to mark this as a defer to the converged repo, then. Will keep this open, however.

[jorangreef]

Thanks.