Use stack-utils for nicer stack traces.

[jamestalmage]

I have extracted node-taps stack cleaning algorithm into it's own module, tapjs/stack-utils.

It creates much nicer stack traces than beautify-stack.js does. There is a bit of work left to do in the stack-utils module, but once these are done, this should be mergeable:

• What should be considered "internal"? tapjs/stack-utils#8 - decide what should be considered internal
• Long Stack Trace Support tapjs/stack-utils#6 - clean long stack traces

Screenshots below.

[jamestalmage]

Before:

After:

[jamestalmage]

Before:

After:

[jamestalmage]

Before:

After:

[vadimdemedes]

Love love love this!

[vadimdemedes]

No need for github: prefix, it will work the same without it.

[jamestalmage]

I just did

npm i -S tapjs/stack-utils#long-stack-traces

and that is how it modified package.json. I want to get that PR merged before we merge this anyways.

[sindresorhus]

npm apparently adds this now, but it's not needed as github is the default for shorthands.

[jamestalmage]

Love love love this!

😄

If you could review the issues and PR's on stack-utils that would be a big help.

[jamestalmage]

Oops. This fixture isn't used anywhere. I just used it to create some of the above screenshots. It should be deleted.

[jamestalmage]

I'm also wondering if we should do something like this:

var opts = {};

// If debug is enabled, don't delete stack trace lines.
if (!debug('ava').enabled) {
  opt.internals = StackUtils.internals().concat([ 
     // ...
  ]);
}

[vadimdemedes]

Probably adding those when debugging is enabled would be useful:

+       /[\\\/]ava[\\\/](?:lib[\\\/])?[\w-]+\.js:[0-9]+:[0-9]+\)?$/,
+       /[\\\/]node_modules[\\\/](?:bluebird|empower-core)[\\\/]/

[jamestalmage]

If debugging is enabled, why not just print everything?

[vadimdemedes]

Or that :)

[sindresorhus]

😁

Looks kinda weird to have it double here:

false == true
AssertionError: false == true

Maybe we can remove the AssertionError?

[sindresorhus]

Maybe use https://github.com/sindresorhus/indent-string here.

[sindresorhus]

Why is the first line not indented? And why do we need to manually indent it? Shouldn't stack-utils do that for us?

[vadimdemedes]

See tapjs/stack-utils#2 (comment), if I'm not mistaken

[jamestalmage]

Yep. Whitespace at the beginning of any multi-line string makes the yaml output much harder to read. stack-utils trims whitespace from the first line.

I guess we could add an indent option to stack-utils.

[sindresorhus]

I guess we could add an indent option to stack-utils.

👍 Can you open an issue on stack-utils so we don't forget to simplify this?

[jamestalmage]

Maybe we can remove the AssertionError?

Sure. stack-utils actually chops the first line of the stack-trace (the message) off anyways. I actually manually add it back in beautify-stacktrace.js. The issue is the reporters only show that for assertion errors. unhandledRejections and uncaughtExceptions would be different. We would just need to rework the reporters so it's their responsibility to print the message.

[sindresorhus]

Can you normalize the paths in stack traces to forward slash? That way they're consistent on all systems and with the added benefit of simpler regex here.

[jamestalmage]

Actually, stack-utils already does that. I'm not sure if it does it before the regexp gets applied, but it probably should.

[sindresorhus]

We would just need to rework the reporters so it's their responsibility to print the message.

👍 Can you open a new issue about that? It's unrelated to this PR, just came to my mind when looking at your screenshots.

[ariporad]

👍

[sindresorhus]

👍

[vadimdemedes]

I think this feature should go into killer-feature list.

[sindresorhus]

@vdemedes Go ahead ;)

[kevva]

This is super nice.