azer / prova

Test runner based on Tape and Browserify

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

use sourcemap

jchris opened this issue · comments

It would be nice to report real filenames and line numbers. I think browserify has good support for source maps but I'm not able to get it to work via the obvious method of changing browser.js so that it calls var b = browserify({debug:true})

screen shot 2014-07-30 at 9 26 56 am

@jchris prova enables source maps actually, you can browse the source code in developer tools but error stacks unfortunately doesn't support it. we have to implement a workaround for that.

btw I don't know why that screenshot should actually show your source code instead of tape. is your prova the recent version? or any chance I can reproduce it?

I should be able to check in my project later today, so I'll drop a link to it so you can play around with it. Too bad there's not an easy way to take advantage of the sourcemaps in the UI.

@azer any chance you can give more detail on why the error stacks don't support source maps? Is it just b/c browserify doesn't create them?

@joeybaker I think browsers don't support it

Hmm… sorry if I asked my question poorly. The stack trace above shows the problem coming from inside tape. While technically true, the real problem is coming from an assertion inside a test file. It would be great if prova could show that (it does when testing in a node env). What is it that browsers don't support that makes this impossible?

browsers create error objects. And the problem is when you create an error object new Error("foobar") in a built file browser doesn't give you a nice stacktrace that shows filenumbers. to reproduce this you can browserify this code: console.log(new Error("foo")) --debug enabled and try running it in your browser

Hmmm… okay, I'm not certain if the sourcemap works or not, but my greater point is that the first line displayed probably shouldn't be from within the tape lib. The actual error came from some test file, and that isn't available anywhere in the stack.

@joeybaker that's right, I remember fixing that actually; da2139e#diff-67fd24a4c811ff9510f6d2b77c4f990fL42

hmmm… doesn't appear to be fixed :(

My team is getting this issue as well. Stack track supplied is a tape stack trace not the actual error from the test.

@thealphanerd @joeybaker I've upgraded Tape to 3.x.x and patched the error stack. Now it should show the actual failing lines for JS, but there might be edge cases. Please try v1.14.1

I just updated the dependency on our project, although unfortunately all our tests pass... so I have no way to check if this is working right now. I'll try and get someone on the team to make something break tomorrow to see if we can see this fix in action!

@azer Great!!! The error now shows correctly! The line numbers don't respect source maps, but this is huge! Thank you!

glad to hear that it worked for you, I don't have enough time to fix source maps at this point but hopefully we'll get better error stacks in the future. actually may be we should create this issue in tape's repo, too