Maximally minimal stack trace standardization

John Lenz concavelenz at
Tue Sep 30 09:28:17 PDT 2014

I don't believe we want source map involved as, as you say, that
information needs to be retrieved separately.
On Sep 30, 2014 5:17 AM, "Fitzgerald, Nick" <nfitzgerald at> wrote:

>  On 9/30/14, 3:44 AM, John Lenz wrote:
> It is a defacto standard.
> On Sep 29, 2014 6:36 PM, "Brendan Eich" <brendan at> wrote:
>> Carl Smith wrote:
>>> If the source URL hack, or some cleaner wrapper for it, was
>>> standardised, it'd make all the difference.
>> Why don't we just make the source URL hack a de-facto standard? That's
>> how evolution happens, in the best case. Cc'ing @fitzgen.
>> /be
> I remember web compat concerns, but if Chrome is exposing the `//#
> sourceURL` to the web in error stacks, maybe we can get away with it as
> well. I'd defer to jorendorff's opinion on this.
> We've also discussed exposing the source mapped location of stack frames
> to JS, but that's even trickier:
> * We don't do any source mapping unless devtools are open, so exposing
> this would leak whether the user is using devtools or not. Not sure how
> serious that is, but it makes me hesitant. On the other hand, always source
> mapping seems impractical, but maybe that's a false assumption.
> * It is a nonstarter to block JS on fetching a source map, so early stack
> traces would not be source mapped, while later ones would be. This sort of
> non-determinism makes me feel :( We could introduce a new async method for
> getting stacks and only source map for these async stacks (or make the new
> method that other branches of this thread are discussing async).
> Interested in hearing everyone's thoughts on this.
> Cheers,
> Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list