Stack traces shouldn't leak into the output

[wycats]

In general, we should always be able to convert JS exceptions into contextual, human-readable error messages. Unfortunately, errors sometimes make it through to the top of the process because we haven't properly handled the error yet. (#943, #944, #928, #921, #919, etc. etc.)

In my opinion, we should have a zero-tolerance policy for stack traces that are reported in raw form to users.

Proposal: If a stack trace makes it to the top of the process, we should capture it, save it off in a long file, and give the user a red error indicating that an unexpected problem occurred, and giving them a command to run to show the original error.

A nice side-effect of doing this is that we can also put other contextual information in the log file and give users a really nice single file to include with bug reports.

[Daniel15]

give users a really nice single file to include with bug reports.

We could automatically include a lot of the information we need for bug reports (OS, Yarn version, Node version, npm version) which would be awesome 😄

Continuing on from your idea of giving a command to show the original error, what if we had a "report bug" command to open up a browser window with the "new issue" page prepopulated with the information? When an error occurs, we'd save the error to a log file, then say something like "To report this as a bug, run yarn report-bug 12345" (where 12345 is some short opaque identifier for the log file). Running that command would pop up a browser at the right URL (eg. https://github.com/yarnpkg/yarn/issues/new?title=foo&body=bar). This'd only work well for graphical environments (ie. not when executing Yarn remotely via SSH) and URLs are limited to ~4000 characters, but it might still be useful.