x)- [ ] bug report -> please search issues before submitting
- [x] feature request
@angular/cli: 1.4.9
node: 8.7.0
os: darwin x64
@angular/animations: 4.4.6
@angular/cdk: 2.0.0-beta.12
@angular/common: 4.4.6
@angular/compiler: 4.4.6
@angular/core: 4.4.6
@angular/forms: 4.4.6
@angular/http: 4.4.6
@angular/material: 2.0.0-beta.12
@angular/platform-browser: 4.4.6
@angular/platform-browser-dynamic: 4.4.6
@angular/router: 4.4.6
@angular/cli: 1.4.9
@angular/compiler-cli: 4.4.6
typescript: 2.3.4
ng serve
N/A
In webpack, there is a watchOptions.aggregateTimeout setting that defines the time (in milliseconds) before initiating a browser reload. This allows multiple changes to one or more files to only trigger building once.
In cli/tasks/build.ts, I see the entry point for watching the files is little more than a pass-through of the cli configuration into the webpack configuration.
TIA!
The default should be 300 milliseconds. Have you found this number to be inadequate? if there is a more optimal number the default could potentially be changed.
@clydin yes, the default is 300ms. Yes, I find it inadequate. But I question the idea of trying to use a one-size-fits-all approach, when something like this will be purely subjective. For what it's worth, I can appreciate the ideal of not over-encumbering everyone with the full configuration potential of webpack (it's a lot, and it could be very easily messed up).
In this case, I am hoping to successfully argue the inclusion of the watchOptions.aggregateTimeout property so anybody can tweak it to their personal preference. My main argument for this is that it only affects development environments (e.g., no side-effects for production builds), and it has the potential positive impact on individual developer productivity.
Thank you!
This could also greatly help in library development when using npm link. The current watch-process fails without any way to recover when a folder from node_modules is removed and re-created.
I think the implementation would be as easy as replicating the logic of hmr as seen here:
https://github.com/angular/angular-cli/blob/b6b8acc1bf9928fc8016d77980dc61e9d978876b/packages/%40angular/cli/tasks/serve.ts#L242
If the team behind angular-cli thinks this would be a good addition, I'd be happy to provide the respective PR.
Most helpful comment
@clydin yes, the default is 300ms. Yes, I find it inadequate. But I question the idea of trying to use a one-size-fits-all approach, when something like this will be purely subjective. For what it's worth, I can appreciate the ideal of not over-encumbering everyone with the full configuration potential of webpack (it's a lot, and it could be very easily messed up).
In this case, I am hoping to successfully argue the inclusion of the
watchOptions.aggregateTimeoutproperty so anybody can tweak it to their personal preference. My main argument for this is that it only affects development environments (e.g., no side-effects for production builds), and it has the potential positive impact on individual developer productivity.Thank you!