Repository navigation
Upstream parts of react-dev-utils #5409
Description
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 :-)
Reacted by Artem Batura
Activity
Timer commentedon Oct 11, 2018
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
prettytoggle...IIRC, we were mostly talking about the ModuleNotFoundPlugin (
packages/react-dev-utils/ModuleNotFoundPlugin.js).edmorley commentedon Oct 11, 2018
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).
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 --WatchMissingNodeModulesPluginsounds 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 :-)
[-]Upstream parts of react-dev-utils/formatWebpackMessages.js[/-][+]Upstream parts of react-dev-utils[/+]stale commentedon Nov 10, 2018
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 commentedon Nov 12, 2018
(not stale)
stale commentedon Dec 12, 2018
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 commentedon Dec 12, 2018
stale commentedon Jan 12, 2019
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 commentedon Jan 14, 2019
stale commentedon Feb 13, 2019
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 commentedon Feb 14, 2019
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 commentedon Feb 14, 2019
Awesome - thank you :-)
edmorley commentedon Feb 14, 2019
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 commentedon Feb 14, 2019
Will start with a webpack plugin that completely massages the messages (likely) then upstream from there.
Timer commentedon Feb 14, 2019
Remember, a lot of what we format is super opinionated and not a good fit for all projects. We'll play it by ear!