Hi @roachjc, i know the webpack monitor is meant to track releases / production builds stats. But i think there is legit use case for using it in a watch mode i.e. webpack --watch or in webpack-dev-server.
For example when between two releases the developer wants to see what introducing new dependencies, or refactoring means for the bundle sizes compared to last builds.
Or when the developer tries to optimize the build setup with different webpack plugins and wants to see if he has achieved the results which wpm suggest. Without stopping and restarting the server, and manually removing the last entry in the stats.json.
What do you think? you can have a look at the commits add decide if this new feature makes sense and i should finish the implementation.

Hi @mbehzad thanks again for another PR!

Commit bb257c0 is great and a much needed error handler, so thank you for that. Would you mind submitting that as its own PR and I will merge it in?

Regarding 0233e8d, here are my thoughts:

It is quite common for the production and development builds to be substantially different. Mixing the two build types in the stats output would compromise wpm's ability to describe the trend of the build over time.

In development mode, the whole build would likely be significantly larger, any libs that have prod and dev modes (eg React) would be different, output filenames could be different etc etc. The charting is organized in such a way that if a single very large build is added, all the other builds would be dwarfed and less readable.

I totally agree with you that there is a legit use case for such a tool, I'm just not sure that WPM in its current form is where it should be. If such a feature was to be included, I would imagine it in a separate view that deals specifically and only with the current dev build served by webpack-dev-server while keeping the main area as only concerned with production builds over time.

I hope that makes sense. I would be interested to hear your thoughts!

Thank you again for your involvement 😀

Hi @roachjc , yes you have a good point. I had a happy case in mind where dev and prod settings are similar. I think an option to "capture" the current stats and show them in the graphs but not "persist" them would allow to compare the current state (in prod mode) with other builds. and/or the frontend allows removing builds from the stats data. for example when a build script was executed one time too often. But that's maybe another feature/PR.
In the mean time i'm gonna revert the last commit. It would be great if you could add couple of sentences for example as part of a FAQ or something to the README regarding why calling wpm in watch mode would throw an error and why it should only track prod builds... a combination of what you wrote here and in couple of other issues. I could then reference that in the console message.