Overwhelming output while twig syntax error

[jrysig]

I'm testing webpack-bundle with clean Symfony 3.2 project. When there is syntax error in *.html.twig, for example missing '}', dashboard is overwritten with error text. Error message is printed every second, it is also included in var/logs/dev.log: [2016-12-03 23:37:14] app.ERROR: Twig_Error_Syntax: Unclosed "block" in... [2016-12-03 23:37:15] app.ERROR: Twig_Error_Syntax: Unclosed "block" in...

It is possible to get nice error output with

maba_webpack:
     twig:
         suppress_errors: false

but it doesn't work well with bin/console maba:webpack:dev-server because server is not restarted on error.

[mariusbalcytis]

Currently maba:webpack:dev-server PHP process starts webpack-dashboard process, which in turn starts webpack-dev-server process.

webpack-dashboard puts everything from stardard output of internal command into left top pane. All other things are taken from socket - server is ran from webpack-dev-server process which gives out statistics about compilation process.

For errors (and log messages in verbose mode) to be shown in that pane it would take to run PHP process from webpack-dashboard. This would require either to run node process in the first place instead of good old app/console (maybe some helper in bin folder is possible) or get something like PHP -> node -> PHP -> node, which is an overkill IMO for displaying log messages inside the console properly.

Furthermore, if PHP is ran from node process, it does not see TTY, which in turn (currently) disables dashboard plugin. Colors would not be available, too, as I remember.

You could test it by setting bin.webpack_server.tty_prefix to [] and running node node_modules/webpack-dashboard/bin/webpack-dashboard.js -- app/console maba:webpack:dev-server.

---

About printing every second - printing is done by Symfony itself as error is called on logger. I don't think that it would be good idea to extend interfaces so that error would not be logged if same one was logged in previous iteration - it would complicate all the code and logic for not so much gain.

Sleep timeout could be extended in case of an error, but again - it would mean that when the error is fixed, it would take more time to start compiling all over again.