You can clone with
HTTPS or Subversion.
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: https://github.com/janekp/mapstrace
The minifier yuglify version 2 seems to have support for source map creation, as does the Closure compiler.
https://github.com/mozilla/source-map/ - Mozilla's implementation of source map consumer by @fitzgen
http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/inspector/front-end/CompilerScriptMapping.js - WebKit's implementation
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.
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 https://github.com/novocaine/sourcemapped-stacktrace, 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.
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 foo.bar(), 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 ...)
@bountin Thanks for the heads up!
First draft of this effort underway here: https://github.com/stacktracejs/stacktrace-gps. Feedback appreciated /cc @hasenstein @bountin @novocaine. You can follow progress at stacktracejs/stacktrace-gps#4
Implement StackTrace.fromError using ES6Promise.
Use StackTraceGPS for source map support for #44.
Filter out stacktrace.js internals by default fixes #65.
Really looking forward to this!
@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
@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!
./node_modules/.bin/webpack-dev-server --inline -d --hot
@mbrgm Thanks for the thorough example. I'll get to this asap (probably before end of weekend).
@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?
@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. :)
@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
// Stack: k@http://ajax.googleapis.com/ajax/libs/angularjs/1.3.8/angular.min.js:118:287
// at http://ajax.googleapis.com/ajax/libs/angularjs/1.3.8/angular.min.js:112:276
// at l.$eval (http://ajax.googleapis.com/ajax/libs/angularjs/1.3.8/angular.min.js:126:83)
any updates on this?