Ignore queued events

[mojavelinux]

Is it possible to configure glob-watcher to ignore all queued events?

The idea is to run a process when a change is detected, but ignore events that happen while the process is still running. Then, when the process is done, begin accepting events again. Is that possible with glob-watcher?

If that's not in scope, just let me know so I know to look elsewhere.

[phated]

@mojavelinux interesting request! I'm open to adding something like this, but I have no idea how to name the option or how it would interact with the queue option. Thoughts? Also, I'm not able to spend much time working on stuff these days so if you could send a PR, that should speed things up.

[mojavelinux]

I'd definitely be opening to following up my request with code.

I'll have to give the option name some thought. My first instinct is to call it ignoreQueued (or dropQueue). But I need to think whether it would be better to have a limit for the queue, one of which could be 0. I'll prototype it to see what makes the most sense.

[phated]

I think we could achieve this by introducing a queue option where you could pass a custom queue that drops events. I think we could even replace the queued argument with that in a breaking release and allow people to set it to null/false if they don't want to use a queue.

[yocontra]

Looking through the code really quick - I think there's two possible modes here, we could do one of them or both:

• For users using the return value from glob-watcher (the instance): If you want to pause events while an async process is running we could expose pause+ resume functions. It would just flip a boolean internally to stop emitting events while in a paused state. Since we are returning the chokidar emitter directly we would probably need to do a little extra to keep it quiet.
• For users who are just using the callback signature: We can make an option (pauseUntilComplete? pauseWhileRunning?) that prevents anything from being queued while running.

One other option is no API change or addition, instruct users to call .unwatch() or one of the other chokidar methods on the returned instance for this behavior. I'm not sure how resource intensive killing the watch then starting it back up again is in chokidar.

As a work-around until we figure out a solution, if you're using the EventEmitter to call your function you can always remove your event listener when your process starts, then add the event listener back when finished.

[phated]

I don't think it's ideal to have people using the watcher directly because we normalize the watch callbacks to match our async handling - this was a huge QoL improvement in gulp 4.

Returning the watcher was really just provided as an escape hatch for people that need to inspect file paths for some reason. I did some rough sketching on making my "queueing" logic an instance so people can inherit/modify from it.