Consider using PrettyError for error messages #1245
Comments
+1 |
@sokra Maybe this would be good for webpack 2? |
+2 it's good instantly |
+3 Would we want to instead make it a flag for |
Would be good to also have a custom formatter like tslint. palantir/tslint#947 |
@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. |
Could somebody point me to the file to add this at? Is there a general "throw an error" method? (maybe |
@mxstbr If I read right, |
these "pretty" errors are pretty noisy. |
@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". |
Yeah, I would rather expose a logging protocol that would allow overrides than stick to some particular solution over others. |
@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 |
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:
This entire stacktrace, and loaders' stacktraces and any other stacktraces should be hidden by default and enabled through a (I'm currently looking at easily 100 lines of a stacktrace including tens of lines of |
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. |
We did implement what @dmitriid suggested. By default no stack trace is shown and only the relevant message. In addition to this everybody is free to use PrettyError in the webpack.config.js. Just add |
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.
The text was updated successfully, but these errors were encountered: