Closed albertinad closed 9 years ago
Perhaps, a better approach to address the issue (tracking modifications caused by own actions) would be to 1) turn off explicitly the processing of the file notifications while the command is being executed; and, additionally, 2) tracking any notifications if they came in during the processing and then explicitly requesting to process them after the command has completed. This will still have the overhead of double-processing changes to bower.json
, but it will provide a consistent approach.
To get rid of double-processing of bower.json
, you could keep track of stat.mtime
timestamp and discard notifications if the file with that timestamp has been already processed (or the state is assumed to be in-sync).
Thanks @busykai ! I will complete the implementation of the approach that you propose (using timestamp) as part of a new PR.
Disabling updating the the Project packages model while an internal command execution that could modify the bower.json file content is taking place. Adding a couple of tests for external and internal modifications of the bower.json file.
@busykai could you review this PR? Thanks!