Fixes webpack/webpack#762

[roblg]

I believe this will fix webpack/webpack#762. I discovered that watch mode was firing an immediate rebuild because it thought files had changed that were changed immediately prior to watch running, but not during the watch build. I think after this change there's still the possibility that sometimes a second rebuild is fired immediately, but the time window for it should be much shorter.

Let me know if I'm missing something.

Cheers!

[jsf-clabot]

All committers have signed the CLA.

[SpaceK33z]

Since this is very tricky logic, a test would be really appreciated.

[roblg]

@SpaceK33z I'll try to pull something together. May not have time today, but should tomorrow.

It looks like there are already a handful of tests that fail on OSX, and I think it's the same issue reported in webpack/webpack#762. I'll see if I can clean those up as well.

Relatedly, I noticed while debugging that the FS_ACCURENCY variable on OSX ends up set to 2000 even though just by examining files on the filesystem, it looks like HFS+ has a 1s accuracy, which IIUC means that even with this PR, if you start watch less than 2s after creating or modifying a file, the watcher is going to report the file as changed, even though it hasn't. Before this PR, that number was 10s, the default value for FS_ACCURENCY. So I guess what I'm asking is: how far down this rabbit hole should I go? If y'all are willing to review, I can take a stab at a slightly larger cleanup (and trying to make the DirectoryWatcher class a little more easily testable), or I can keep it simple and we can all live with files being created <2s before the watcher starts immediately being reported as change.

[sokra]

Thanks