Customize console output

[fgarcia]

• Operating System: 10.12.6
• Node Version: v8.4.0
• NPM Version: 5.4.2
• webpack Version: 3.6.0
• webpack-dev-server Version: 2.8.2

• This is a feature request
• This is a modification request
• This is a bug

For Features; What is the motivation and/or use-case for the feature?

Although I can start webpack-dev-server programatically, it is not clear how to capture the console output.

I want to launch a set of services from one single script. Each of my services print to the stdout with a prefix like [service] some text but I don't see how to manage the output from webpack-dev-server

I do not want to use the quiet option. I want to print errors and reload / re-compile notifications. But I want to customize the output. I would expect two ways:

• custom logger
• emitted events

[shellscape]

(I clicked the close button by accident, whoops!)

WDS console/terminal output really shouldn't be changed from the perspective of the module - the output is specifically tailored to the lifecycle of the module and encouraging that to be changed isn't something I think we'll be keen on. That said, you could pipe the output from the webpack-dev-server command to another script that could examine the output as it's piped and manipulate it there. https://gist.github.com/mhart/2585671 and https://gist.github.com/polotek/977813 would be good starting points if your script accepting the piped data were written in Node.

We'll leave this open for discussion for a day or two in case anyone has some thoughts that'd convince us to reverse course on this, but I think piping to another script is the way to go here.

[fgarcia]

Touching the stdout seems kind of scary to me. I try to avoid similar approaches since I always caused more pain than glory taking that approach, specially when more than one of the combined tools require that. I never managed to integrate well tools that require touching the stdout/stderr.

From my point of view the easiest solution would be passing a custom logger parameter (or custom 'console'). A more versatile solution would be having the server to emit different types of signals and run completely silent. However if not many people need this feature, it would be better to just have the first approach. Less intrusive, less feature creep and the option for a custom logger is a very common pattern.

[shellscape]

Well the exception here is that logging in this module has always been a problem. We need to get that on track before we even think about throwing more complication into the mix with the ability for people to manipulate the output. While I understand your use-case, I don't think there's a high demand and don't think it's the right time for the addition of a feature like that.

[fgarcia]

My main concern when requesting features is not asking for low value features that increase the feature creep of free projects. I understand my use-case might not be common, so if this issue gets closed, at least I would like to write down my case story:

Basically I want to solve my "one command to start working" job. It is great having webpack as compiler and webserver, but I also need to start my backend (and sub-services / worker), get my tests to recompile if a file is modified, sync all my devices with browsersync...

One tool for this job is Foreman, however I like building my one "start.js". Not only I want one terminal window with all my development activity / traces, I want to fine tune the amount of noise I must track.

From webpack I only want to know two things

• if it starts [re]compiling
• if the result was an error or success

Now I don't think the "provide custom logger" is what I would like the most. I guess running in total silence "quiet mode" and emitting those two signals would be best. If people need more signals, they can open a new issue and explain the new ways they want to extend the tool

[fgarcia]

ops, now after writing I realized that the title of this issue no longer represents my real issue 😱

[shellscape]

No worries, issues do evolve. I think what you're going for is pretty common; simplification of tooling. But I think the want for webpack-dev-server to make that easier for you is a little bit of a stretch. The mission of the module is to make developing and debugging with wepback a breeze, but not to assist with specific approaches to tooling - it'd be impossible to cater to the tooling needs of everyone who uses the module. I really think your best bet is going to be to redirect output, or pipe output, to another script and parse it. That way you can do whatever you'd like to without limitation. Going to close this one again for those reasons and your updated use-case. Much appreciate working through this one.