-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add autoWatchDelay option #2331
Add autoWatchDelay option #2331
Comments
Think the thing most of us would like to have is a system that allows us to debounce the incoming changes till no further changes have occurred for an x amount of ms. A perfect example of this is illustrated within RXJS: Having an option like that would be very useful. Stand alone version of debounce: Which would mean the following function probably would have to be modified: https://github.com/karma-runner/karma/blob/master/lib/watcher.js#L93 Once i change the bind function to this i have the desired behaviour:
|
@schippie this is exactly what I'm after. |
Sounds good to me. I agree it does make sense to change the option to this behaviour. |
I ran into this exact issue - chokidar has a nice option called awaitWriteFinish which solves this problem quite well. |
|
You're right - opened issue #2420 to discuss a different but related issue. |
- renamed batchInterval to autoWatchBatchDelay to aid in greppability. - Modified debouncing tests to wait on promises. - Added documentation explaining how list.removeFile is different from list.addFile and list.changeFile. Closes karma-runner#2331
- renamed batchInterval to autoWatchBatchDelay to aid in greppability. - Modified debouncing tests to wait on promises. - Added documentation explaining how list.removeFile is different from list.addFile and list.changeFile. Closes karma-runner#2331
- renamed batchInterval to autoWatchBatchDelay to aid in greppability. - Modified debouncing tests to wait on promises. - Added documentation explaining how list.removeFile is different from list.addFile and list.changeFile. Closes karma-runner#2331
- renamed batchInterval to autoWatchBatchDelay to aid in greppability. - Modified debouncing tests to wait on promises. - Added documentation explaining how list.removeFile is different from list.addFile and list.changeFile. Closes karma-runner#2331
- renamed batchInterval to autoWatchBatchDelay to aid in greppability. - Modified debouncing tests to wait on promises. - Added documentation explaining how list.removeFile is different from list.addFile and list.changeFile. Closes karma-runner#2331
Just a note for future searchers who find this, the second half of making this work for testing ClojureScript files is to disable the caching of any files written by the compiler. The Google Closure Compiler (GCC) writes files to disk in chunks. By default, Karma will cache the files on disk when serving web requests. However there is a race condition that exists where:
The fix is to update your file watchers to set
|
Problem
When incrementally recompiling ClojureScript, many files are changed as the compilation process runs. Currently, it is difficult to use Karma to autorun tests after detecting a ClojureScript recompile, because as soon as the first file is changed, Karma wants to rerun the tests.
Current behaviour
There is a config option
autoWatchBatchDelay
available which at first seems like it would be ideal for this use case. It starts a timer after it detects the first file system change, and waits n milliseconds before running tests. It is possible to use this option, but it is suboptimal.The timer starts from the first change detected, so when configuring this parameter, I need to specify what the maximum time my ClojureScript compile could take, so it doesn't start rerunning while recompiling. I can shoot for a low number that my app will recompile in (say 1 second), but then will hit problems if an incremental recompile takes longer (which happens from time to time when editing certain files).
Proposed behaviour
I propose that there is a new option
autoWatchDelay
(or perhaps changing the behaviour of the current option) to start the delay timer from the last filesystem change detected, waiting n more milliseconds before starting the tests. In practice this might look like resetting the timer, each time a new file change was detected.IMHO this behaviour is probably closer to what most people are wanting when they use
autoWatchBatchDelay
.The text was updated successfully, but these errors were encountered: