Better logging

[jaredpalmer]

Really want improve logging. Seems like it is inevitable that we drop react-dev-utils/formatWebpackMessages and use a custom formatter. This would allow us to have one call to

const multiCompilers = compile([serverConfig, clientConfig])

In multi-compiler mode, we can still pass the respective clientCompiler to webpack-dev-server and watch the serverCompiler in pretty much the same way. However, we would then be able to write truly universal logger (which would look a lot like formatWebpackMessages, but handle multiple configs).

[jaredpalmer]

Going to post some screenshots of my ideas.

[jaredpalmer]

Razzle Loading/Compiling ... (probably powered by Ora)

Razzle Errors pipe below:

[jariz]

@jaredpalmer Did you already start on this?
Sounds like a fun issue to tackle!

[jaredpalmer]

Nope. Go for it!

I was talking to Sean Larkin at React Rally about Webpack and unfortunately there is literally zero way to tell if the errors are identical or not. So despite the current logger, we really should be showing both at all times.

[jariz]

hey @jaredpalmer, I think my PR was a bit too crazy and unstable regarding the UI side of things, but I still really liked the multicompiler approach and the general direction it was going.
It made for a single compiler rather than 2 instances (more clear codebase and probably better for performance) and it would also show an error overlay when a server side compile would fail, which - I thought - was really cool.

Also the UI side of things could be toned down a bit with a less intrusive approach like just clearing the console whenever the server/client bundle becomes invalid, rather than having them display at all times like my PR had.

Let me hear what you think!

[jaredpalmer]

I’d be open to exploring it. How does multicompiler deal with the making the hashed names client assets available to the server? Is there a plug-in?

[jariz]

It 'solves' it be concatting the hashes together. I modified the webpack client to only grab the first part because it would attempt to accept server side HMR's otherwise.

[stale]

Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal.

[stale]

ProBot automatically closed this due to inactivity. Holler if this is a mistake, and we'll re-open it.