New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using PrettyError for error messages #1245

Closed
AriaMinaei opened this Issue Jul 13, 2015 · 17 comments

Comments

Projects
None yet
10 participants
@AriaMinaei

AriaMinaei commented Jul 13, 2015

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

image

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.

screenshot

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:

image

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

This comment has been minimized.

krasnoperov commented Sep 11, 2015

+1

@bebraw

This comment has been minimized.

Member

bebraw commented Nov 14, 2015

@sokra Maybe this would be good for webpack 2?

@jhabdas

This comment has been minimized.

jhabdas commented Dec 19, 2015

+2 it's good instantly

@TheLarkInn

This comment has been minimized.

Member

TheLarkInn commented Feb 24, 2016

+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

This comment has been minimized.

prabirshrestha commented Feb 24, 2016

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

@jhabdas

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Member

sokra commented Sep 14, 2016

these "pretty" errors are pretty noisy.

@jhabdas

This comment has been minimized.

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

@TheLarkInn

This comment has been minimized.

Member

TheLarkInn commented Sep 15, 2016

@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

This comment has been minimized.

Member

TheLarkInn commented Sep 15, 2016

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

This comment has been minimized.

Member

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

This comment has been minimized.

jhabdas commented Sep 15, 2016

@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

This comment has been minimized.

dmitriid commented Oct 5, 2016

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 comment has been minimized.

webpack-bot commented Sep 6, 2017

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.

@webpack-bot webpack-bot added inactive and removed inactive labels Sep 6, 2017

@sokra

This comment has been minimized.

Member

sokra commented Sep 7, 2017

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.

@sokra sokra closed this Sep 7, 2017

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