Support for source maps? #44

WhyEvenTry opened this Issue Dec 10, 2012 · 24 comments


None yet

It would be nice to have support for source maps, because stack traces for minified concatenated files are quite useless. This would seem a most excellent enhancement :)

This github project may have it:

The minifier yuglify version 2 seems to have support for source map creation, as does the Closure compiler.

bilalq commented Feb 3, 2014

Are there any plans for bringing this feature in?


+1 - I'd definitely like to see stacktraces with the original sources, if a sourcemap is given.



@JamesMGreene JamesMGreene referenced this issue in qunitjs/qunit Jun 10, 2014

Support source maps (Browserify) #590


What this also requires is the ability to parse and inspect the pieces of a stacktrace, which stacktrace.js simply doesn't do. This was the whole reason I made stackinfo.

I actually have code to do this kind of thing in deadunit-core using stackinfo. Basically it just finds and downloads the sourcemap, then translates the exception. Maybe I'll pull that out and release it as an entirely separate module at some point..


I suspect this is probably out of the scope of stacktrace.js as it implies fetching and parsing sourcemaps in JS.

I have just pushed a module which does do only that part to, currently browser support is Chrome only which may solve your problem if you are just trying to view failing tests or errors on your dev machine.

If stacktrace.js outputted a standard browser agnostic format it would be easy to integrate the two (currently seems like it doesn't [ironic])


@novocaine the project I mentioned stackinfo does create a browser agnostic output.


@fresheneesz thanks, I am considering using stackinfo but wouldn't it be nicer if stacktrace.js outputted standardised information in the first place? Then I could use one library rather than two chained ones. I can also see stackinfo hasn't been as exhaustively cross browser tested as stacktrace.js, so it might not 100% solve the actual problem.


@novocaine I would very much appreciate the help with cross-browser testing. I actively support it and would quickly fix any issues you find. Also, stackinfo uses stacktrace.js, so it really is one module - I'm not sure why you think 1 module is better than 2 chained together tho. Its essentially the same code separate as it would be together.

bountin commented Sep 3, 2014

Just a tip from me trying to combine stackstrace.js and sourcemapped-stacktrace: Firefox and Chrome (and maybe other browsers too) have different opinions where a function call on an object starts. When calling, one reports the letter f of foo as column and the other one b of bar.
So either stacktrace.js solves this by normalizing this, or the source map resolver is a bit more liberal of input. (Or we wait till the browsers adopt a common format but I don't think that this will happen in the near future ...)

eriwen commented Sep 3, 2014

@bountin Thanks for the heads up!


Yes, this is a limitation of sourcemapped-stacktrace, it only supports
Chrome presently.

+1 for stacktrace.js normalising the output for at least the most common

On Thu, Sep 4, 2014 at 3:37 AM, Eric Wendelin

@bountin Thanks for the heads up!

Reply to this email directly or view it on GitHub
#44 (comment)

@eriwen eriwen removed the waffle:ready label Oct 7, 2014
@eriwen eriwen added this to the Unscheduled milestone Oct 8, 2014
eriwen commented Nov 8, 2014

First draft of this effort underway here: Feedback appreciated /cc @hasenstein @bountin @novocaine. You can follow progress at stacktracejs/stacktrace-gps#4

@eriwen eriwen modified the milestone: 1.0, Unscheduled Nov 9, 2014
@eriwen eriwen pushed a commit that referenced this issue Nov 28, 2014
Eric Wendelin Implement StackTrace.fromError using ES6Promise.
Use StackTraceGPS for source map support for #44.
Filter out stacktrace.js internals by default fixes #65.
mbrgm commented Feb 3, 2015

Really looking forward to this!

eriwen commented Feb 3, 2015

@mbrgm You can test it out with what's on master. Your feedback would be greatly appreciated. Please submit any issues to stacktracejs/stacktrace-gps



mbrgm commented Feb 4, 2015

@eriwen I tried it, but maybe it's not working because I'm using webpack.

I put together a quick example. If you look at src/scripts/index.js#9-12, that's were I'd like to print the stacktrace of the caught ReferenceError, which is created when requiring app.js.

I would really appreciate if you could have a look at the example and maybe tell me what I'd have to change. You can run a test server from within the repo directory using ./node_modules/.bin/webpack-dev-server --inline -d --hot. Thank you!

eriwen commented Feb 4, 2015

@mbrgm Thanks for the thorough example. I'll get to this asap (probably before end of weekend).

eriwen commented Feb 6, 2015

@mbrgm I got your example working by simply changing your package.json to point to stacktrace.js/dist/stacktrace.min.js which includes all dependencies.

I ran ./node_modules/.bin/webpack and served up the build directory and got 7-entry Stack Trace. Is that what you wanted?

Aside, is there one thing that would've made the install/use process easier for you?

mbrgm commented Feb 9, 2015

@eriwen Could you maybe fork and push your working version? I'm able to get a stacktrace as well, but all of the entries point to the created bundle.js; the webpack-generated sourcemaps don't seem to be considered for resolving.

Edit: Of course a gist with the patch would work as well. :)

eriwen commented Feb 9, 2015

@mbrgm Ah, yes I misunderstood you.

That said, I've made some progress and I believe I've found a case where stacktrace-gps is failing too fast (it tries to GET the webpack:/// url from the source map and the browser throws an access denied error).

This has been very valuable. I'm going to get this fixed, then send you a pull request to your example repo as soon as I can!


BTW, if anyone is looking for a one-time way to decode an exception (instead of planting client -side code to do it), you can use this:

I copied the script in
and modified it a bit to handle Mozilla stacktraces (that have a slightly different format).

If you get CORS errors (i.e., no Access-Control-Allow-Origin header) in the console, then you can use my AppEngine as a proxy by using: decode.html?yoavfetchurl

    // Mozilla: 
    // Stack: k@
    // Chrome: 
    // at
    // at l.$eval (

any updates on this?


Seems like the initial request is being taken care of by Any outstanding issues with that project should be reported over there.

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