You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So recently I got problems in webpack, where the watcher is spamming "compile" events for files that are updated before watching starts. The rabbit hole was deep, but led me to watchpack.
So:
So at some point doInitialScan is processed in DirectoryWatcher.
This, at least for files, runs setFileTime
As the inital flag is set, this this.files[filePath] = [initial ? Math.min(now, mtime) : now, mtime]; mostly equals to this.files[filePath] = [mtime, mtime];, because the file mtime will be smaller the time now (in case I edited file before running watcher).
Next at some point it gets to process.nextTick and var ts = data[0] === data[1] ? data[0] + FS_ACCURACY : data[0]; and if(ts >= startTime)watcher.emit("change", data[1]);
As this data[0] === data[1] is true (check point 3), FS_ACCURACY is added. So ts is bigger than startTime (delivered from webpack compiler it's self.startTime = Date.now();).
So for aprox 10 seconds (FS_ACCURACY = 10000 milis) it'ss spamming compile events, until the date now reaches file mtime+10 secs.
Activity
trsh commentedon Jul 18, 2017
Any comments?
AlexGalays commentedon Jul 25, 2017
Same as #25
?
trsh commentedon Jul 25, 2017
@AlexGalays yes
alexander-akait commentedon Feb 8, 2018
@trsh duplicate #53?
YurySolovyov commentedon Feb 8, 2018
Adjusting concurrency seems like a crutch, race condition like that should never happen by design.
If that means things will go slower, it is fine, cause spamming like that confusing and slowing developers anyway.
Please, dear core team, do not trade speed for correctness and robustness.
sokra commentedon Jul 10, 2019
closing as it's a duplicate