-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FSEvents watcher #97
FSEvents watcher #97
Conversation
Keep getting |
src/fsevents_watcher.js
Outdated
}); | ||
} | ||
|
||
function emit(stat) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the this
should be changed to self
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah sorry fixed locally and didn't update the branch
A very quick test using the cra-desktop and fixing up the There was an issue with creating files though. If I create a file using SublimeText, { path: '/Users/Ro/www/create-react-app/test-watch/something.js',
event: 'modified',
type: 'file',
changes: { inode: false, finder: true, access: false, xattrs: true },
flags: 110848,
id: 94649282 } If I create a file with { path: '/Users/Ro/www/create-react-app/test-watch/touch.js',
event: 'unknown',
type: 'file',
changes: { inode: false, finder: false, access: false, xattrs: false },
flags: 65792,
id: 94649923 } Tried both of these a few times, and got the same result each time. |
@ro-savage the created/modified event seems to be known, see the comment in fsevent test |
src/fsevents_watcher.js
Outdated
|
||
FSEventsWatcher.prototype.emitEvent = function(type, file) { | ||
var self = this; | ||
console.log('here'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^
src/fsevents_watcher.js
Outdated
this.watcher.stop(); | ||
this.removeAllListeners(); | ||
if (typeof callback === 'function') { | ||
setImmediate(callback.bind(null, null, true)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious why setImmediate
over process.nextTick
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no reason this can be nextTick
"homepage": "https://github.com/amasad/sane" | ||
"homepage": "https://github.com/amasad/sane", | ||
"optionalDependencies": { | ||
"fsevents": "^1.1.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm nervous to introduce the node-gyp dependency here. Although it is an optional dependency the ergonomics around failed optionalDependencies is still quite poor for those with funky environments.
On a positive note, it looks like fsevents does seems to do its best to avoid pain here:
- only run for OSX https://github.com/strongloop/fsevents/blob/master/binding.gyp#L6
- only run in OSX https://github.com/strongloop/fsevents/blob/master/install.js#L1
- uses
node-pre-gyp
to install a binary when possible.
One last concern is if the binaries themselves are not stored in the registry, so companies with private registries (for insulation from the outside world) might become unhappy. For this reason, if we proceed I would like to recommend this be at-least a major version bump.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah agreed. I'm really reluctant to do it. But the problem is badd enough that the NodeWatcher is not usable on some machines (including mine).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@amasad if you gotta, mind doing a major version bump? or...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
of course
src/fsevents_watcher.js
Outdated
}); | ||
} | ||
|
||
function emit(stat) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^.
@ro-savage yeah it seems like we need to handle these |
Worth taking a look at how Chokidar uses fsevents? It's been working pretty well in webpack (even if it's not at FB scale). |
Chokidar is doing exactly what @amasad mentioned. It keeps an object that contains every item tracked and anytime fsevents fires a change/created/unknown event it checks it's registry of items and decided what actually happened. Feels extreme, but it appears the only way to make sure its correct. So that's Option 1. Option 2 (I actually have no idea of the implications of having an object with tens of thousands of properties in node, maybe it doesn't cause any issues with speed/memory) Option 3 What's your thoughts @amasad ? |
Not extreme at all. We already do that for the node watcher. The reason Sane exists (and the reason for the name) is because native node watcher was garbage (it's still is I guess). See this.
That's a non-starter -- the whole point of Sane is to paper over multiple watcher backends with the same API so that consumers can slide them in and out as they please.
More than happy to deprecate if the major consumers think they can live without it /cc @cpojer, @stefanpenner, @gaearon et al. My guess is that there is still value in the abstraction this provide so that you can switch between the different watchers depending on the platform and/or capabilities. |
@amasad Do you think you could find the time to finish up "option 1"? |
@gaearon yeah, most likely do it this weekend. |
Friendly ping 😄 Do you think you could finish this, or maybe somebody else could help? |
Yes made some progress. Ill cleanup, send an update on progress later today. |
Ok this is passing tests and looks like its working well. I'll wait for comments then merge and release an alpha. Sorry for the delay @gaearon. |
No worries, thank you so much for the followup! Fingers crossed. |
Is it correct that we have to modify jest on this line https://github.com/facebook/jest/blob/79eed2558402d660f914b47833658625399bbaff/packages/jest-haste-map/src/index.js#L569-L571 |
Ok success, tested facebook/create-react-app#2393 with repo https://github.com/thisconnect/cra-desktop rm -rf node_modules/sane
rm -rf node_modules/jest-haste-map/node_modules/sane
npm i amasad/sane#fsevents
vi node_modules/jest-haste-map/build/index.js
# changes line 571
# from ": sane.NodeWatcher;"
# to "sane.FSEventsWatcher;"
npm t
# WORKS with no error!
testing the error one more time rm -rf node_modules && npm i && npm t
# old error works too :) |
Sorry been on holidays. Tested it with a Create React App where I just installed a bunch of large npm packages. Came out at 1200+ packages and approximately 50,000 files. Died on old sane. Worked fine on this branch. I'd say go ahead and release. |
hey all... is there something that core can do to hell with this regression? we are getting some new test infra for osx soon, which should hell find regressions. |
Seems to work in my testing! Is there anything else holding this back? |
@ro-savage and @gaearon did you patch jest-hastle-maps as in #97 (comment) or was sane a drop in replacement? |
I did patch that file, yes. |
@gaearon I'm OOO. But I'll find time for the release. Sorry bout the hold up. @MylesBorins thanks for the offer. I think the most important thing is to test against really large directories. This is vague in my memory but my understanding is that I you look at watchman and the npm module fsevents does a better job at reusing watches (and even multiplexing I the case of watchman) where is native node watcher is resource hungry. |
Merged. And sent a PR to jest. jestjs/jest#3902 |
This is to fix regressions with the NodeWatcher on macOS. More info here: amasad/sane#97
This is to fix regressions with the NodeWatcher on macOS. More info here: amasad/sane#97
This is to fix regressions with the NodeWatcher on macOS. More info here: amasad/sane#97
There seems to be some kind of regression with the node watcher in MacOS serria:
This adds another watcher that consumers can use for MacOS.