Consider using PrettyError for error messages

[AriaMinaei]

Webpack's error messages are a bit hard to read and could use some formatting:

Have you guys considered using a package like PrettyError for formatting webpack's error messages? PrettyError helps make stack traces more readable, and it's very easy to integrate into other packages.

You could also use RenderKid for formatting the rest of webpack's logs. RenderKid has features like text-wrapping, so that lines of a paragraph wrap inside the paragraph's margins, unlike this:

Both PrettyError and RenderKid can be customized with css-like rules, so that webpack can define a common theme for its console output, regardless of which plugin those messages come from.

ps. I'm the author of both packages, and I can help with the integration process.

[krasnoperov]

+1

[bebraw]

@sokra Maybe this would be good for webpack 2?

[jhabdas]

+2 it's good instantly

[TheLarkInn]

+3 Would we want to instead make it a flag for --prety-error or let them set it all the time. Similar to --colors.

[prabirshrestha]

Would be good to also have a custom formatter like tslint. palantir/tslint#947

[jhabdas]

@TheLarkInn Makes sense to have flags or some other configurable way to otherwise leverage pretty's black box capabilities. FWIW Chrome Dev Tools has woeful support for hiding React internals.

[mxstbr]

Could somebody point me to the file to add this at? Is there a general "throw an error" method? (maybe lib/Stats.js? I'd love to have this. /cc @TheLarkInn @bebraw

[bebraw]

@mxstbr If I read right, Stats.jsonToString would be a good place to poke. Perhaps a good way to prototype it would be to figure out good formatting against Node and stats you get through it. Once you have stats JSON with an error, you can iterate on the formatting fast.

[sokra]

these "pretty" errors are pretty noisy.

[jhabdas]

@sokra check out the blackboxing feature. it allows one to hide the frames of the stacktrace which are not interesting/applicable, such as vendored code

[TheLarkInn]

@jhabdas so we would love to see a PR on this. And like @sokra said it may not be for everyone so a flag would be very ideal. We can discuss further through the PR process as well.

[TheLarkInn]

Or maybe instead to empower better plugins for this, I have always been interested in the investigation into creating a new Tapable instance for webpacks output system. This could allow features like this to be created through plugins, in addition could solidify and standardize across the board how plugins, maybe loaders hook up into a standard console output "template" or "instance".

[bebraw]

Yeah, I would rather expose a logging protocol that would allow overrides than stick to some particular solution over others.

[jhabdas]

@TheLarkInn @bebraw The idea of a tapable instance sounds great (the link's broken by the way). I'd personally lean towards a code for today mentality, though, and put this under a flag. Though I understand the webpack codebase is probably getting a bit gnarly. IMO the essence of this issue is more dev-friendly error outputting, however it's done.

If there are any other ideas on how blackboxing could be done with the current installment, I'd love to hear about it. FWIW, since React became a thing step debugging in the browser has become quite a bit more complex and I've seen many developers backpedaling to console.log and generally wasting their time. Perhaps more pressing is to make step debugging easier in the browser.

[dmitriid]

A more relevant question would be: if I'm not a webpack/plugin developer, there's really no value in these errors. As a developer I want to see one single error: what happened:

• A loader failed to parse file X at line Y expecting Z.
• webpack failed to find module M referenced from module N even though it looked at directories O, P and Q
• etc.

This entire stacktrace, and loaders' stacktraces and any other stacktraces should be hidden by default and enabled through a -enable-verbose-logging switch.

(I'm currently looking at easily 100 lines of a stacktrace including tens of lines of Parser.pp.<> at webpack/node_modules/acorn/dist/acorn.js and Storage.finished at node_modules/enhanced-resolve/node_modules/graceful-fs/graceful-fs.js where I need only one single line: ERROR in [default] xxx.js:3:15 Expression expected.)

[webpack-bot]

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[sokra]

We did implement what @dmitriid suggested. By default no stack trace is shown and only the relevant message. --display-error-details show the complete stack.

In addition to this everybody is free to use PrettyError in the webpack.config.js. Just add require('pretty-error').start(); on top.