Consider using PrettyError for error messages #1245

AriaMinaei opened this Issue Jul 13, 2015 · 15 comments


None yet

9 participants


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.



bebraw commented Nov 14, 2015

@sokra Maybe this would be good for webpack 2?

jhabdas commented Dec 19, 2015

+2 it's good instantly


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


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

jhabdas commented Feb 24, 2016

@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 commented Jun 26, 2016

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 commented Jun 26, 2016

@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 commented Sep 14, 2016

these "pretty" errors are pretty noisy.

jhabdas commented Sep 14, 2016

@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


@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.


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 commented Sep 15, 2016

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

jhabdas commented Sep 15, 2016 edited

@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 commented Oct 5, 2016 edited

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment