Provide a way to silence "wps: Build 18adad2 replaced:" messages

[EvHaus]

Expected Behavior / Situation

It would be good to keep the browser developer console clear of any webpack-plugin-serve noise.

Actual Behavior / Situation

Currently, the console is updated with a message saying "wps: Build 18adad2 replaced:" on every HMR update. This can get very noisy and clutter the development console.

Modification Proposal

Could we add some flag to webpack-plugin-serve to disable these update messages?

[matheus1lva]

We can add a flag to silence the output. We have to find a good way to implement it.

[shellscape]

Well hang on there a sec @playma256 😄

I know that the other dev servers have options to pick and choose which levels of console output are displayed. But I think the focus is slightly misplaced. This feature (displayed which builds were updated) is intended to be useful. Knowing which build hash an HMR update is on can be very useful if trying to track down a bug. With that, if a particular feature isn't useful, then it should be examined and considered for modification, or in the extreme case, removal.

So it's prudent to ask a few things first:

• how many of these messages are you seeing in a single session (between starting and stopping the server)?
• how often are you making changes that affect HMR while the server is running?
• could different development patterns/practices be used to decrease the number of times HMR is triggered? (I ask because webpack rebuild and HMR tends to be an expensive process)

[EvHaus]

how many of these messages are you seeing in a single session (between starting and stopping the server)?

It's typical for some developers on my team to start a server at the start of the day and leave it running for the full 8 hour work day. Within that time, any Ctrl+S save in the editor would trigger an HMR update as they work on tasks. The frequency of this will depend on a particular dev, but personally, I tend to press Ctrl+S very often (after every few lines of code). So I'd get hundreds of these messages in my console within a few hours easily. I might not necessarily review at the HMR changes for every Ctrl+S, but the HMR will trigger for each one.

how often are you making changes that affect HMR while the server is running?

If you're actively working on some client-side code, it will be on every Ctrl+S. Are you saying there's a way to make a change that won't trigger HMR? I thought any JS change would trigger it (provided you're editing code that affects the currently visible page).

could different development patterns/practices be used to decrease the number of times HMR is triggered? (I ask because webpack rebuild and HMR tends to be an expensive process)

I'm happy to discuss alternatives. Do you have any recommendations/suggestions? For what it's worth, before using webpack-plugin-serve we've been using webpack-serve and it handled our current workflow without any issues.

[shellscape]

Are you saying there's a way to make a change that won't trigger HMR?

Indeed! https://webpack.js.org/plugins/watch-ignore-plugin/ and https://webpack.js.org/configuration/watch/#watchoptions-ignored

before using webpack-plugin-serve we've been using webpack-serve

😄 the burden of too many client options is something that I didn't successfully manage in webpack-serve. So yes, let's discuss alternatives!

Some that come to mind:

• silencing all browser log output
• some sort of filter method for the log
• a client.log option for handling the log how a user sees fit

Any others that come to mind? The log for WPS is super simple, and I'd like to avoid injecting a larger library here (like loglevelnext, which is in webpack-serve).

[EvHaus]

My vote would be for a simple flag/option to silencing all browser log output. I believe this will also have the smallest surface area impact to the plugin so it shouldn't add much support overhead.

There are two things being printed to the log right now:

• The build hash number. I've been using HMR and webpack for years, and I have no idea what the hash is for. It might be useful to someone, but for people just trying to build their apps -- I imagine it's not very helpful.
• An array file paths which reloaded as a result of HMR. This was a new one to me after switching to webpack-plugin-serve and I must admit I can see value in this information. It helps troubleshoot HMR configurations, ensure code splitting is working correctly and validating that an HMR update did in fact occur successfully. That being said, I see this being useful for initial HMR configuration/debugging, but in most day-to-day operations, I would prefer this info to be hidden.

[shellscape]

Sounds reasonable to me.

(one caveat: in the future, if a user happens to request further, more granular control over the client log (we'll almost certainly make that a vote as well), the most likely direction will be implementing client.log and letting the user dictate the behavior they want to see.)

[mindpivot]

ok I have a wild idea completely out of left field for this one - maybe remove all logs from the client console and implement a DevTools extension/tab a la React & Redux DevTools which could output webpack's console output as well as the HMR logs to Chrome. that in conjunction with the helpful browser alerts would be a good combination for keeping track of what's going on during development

in light of something like that, i vote for keeping the logs in the devtools console with potential options to suppress the logs

[stnwk]

Would love to have an option like client.log and being able to decide what should be logged and what shouldn't :)

[shellscape]

@stnwk I'll open a new vote issue for that, and we'll see how much traction that gets.

Update

Actually, with the NormalModuleReplacementPlugin plugin, this is possible relatively easily, since the log.js module is very small:

new webpack.NormalModuleReplacementPlugin(
  /webpack-plugin-serve\/lib\/client\/log\.js/,
  rootDir + '<your log definition filename>')
)