Upstream parts of react-dev-utils

[edmorley]

The react-dev-utils package currently includes a webpack message formatter that aims to clean up the console output, smoothing over some of its rough edges:
https://github.com/facebook/create-react-app/blob/master/packages/react-dev-utils/formatWebpackMessages.js
https://github.com/facebook/create-react-app/tree/master/test/fixtures/webpack-message-formatting

It would be great to upstream these fixes to webpack/the various loaders so the whole webpack community can benefit, whilst also reducing the maintenance burden for the CRA team - as mentioned in:
#5174 (comment)

CC @Timer :-)

[Timer]

I don't think it's likely, but we can try. We're very opinionated on how we strip down the errors.

Maybe if webpack added a pretty toggle...

IIRC, we were mostly talking about the ModuleNotFoundPlugin (packages/react-dev-utils/ModuleNotFoundPlugin.js).

[edmorley]

I don't think it's likely, but we can try. We're very opinionated on how we strip down the errors.

Glancing at the formatter it seems a good start would be for webpack to add a stats option that controlled whether the "Module: ..." boilerplate was added or not, and perhaps even allow loaders to declare that their output should not be wrapped (which would allow eg eslint-loader to disable it, given the filepath etc is repeated within its own message).

IIRC, we were mostly talking about the ModuleNotFoundPlugin

Ah, yes. I'm happy to morph this issue into a general "upstream parts of react-dev-utils" issue - reading through the various files in there, many are really bug fixes that belong upstream (or in some cases might have been fixed already -- WatchMissingNodeModulesPlugin sounds related to the issue fixed in webpack/watchpack#69 for example).

It just would be a real shame for {CRA, Neutrino, vue-cli, ...} to all have to implement their own custom fixes for issues that could be upstreamed and benefit the community as a whole :-)

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[edmorley]

(not stale)

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[edmorley]

(not stale)

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[edmorley]

(not stale)

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[Timer]

We're going to be shipping a package that does this soon. I'll close this issue b/c it's become noise at this point.

Will ping you, @edmorley!

[edmorley]

Awesome - thank you :-)

[edmorley]

By shipping a package, do you mean "try where possible to fix things upstream (or at least file issues against them), and only then ship a package"? ;-)

[Timer]

Will start with a webpack plugin that completely massages the messages (likely) then upstream from there.

[Timer]

Remember, a lot of what we format is super opinionated and not a good fit for all projects. We'll play it by ear!