From:  John Lenz <>
Date:  18 Mar 2014 08:11:48 Hong Kong Time

Re: better document the "names" field in Source Maps


Yeah, it isn't clear and was left in primarily because it have any cost
associated with it. But yes, the intent was to provide to link to the
original names used for a variable, with the Closure Compiler's various
form of variable and property name forking and joining (when fully
optimized) there is no way to use a simply map of names, so you need to
provide it at the place of reference.

But no one has really taken advantage of this for a while as Joey points
out .

On Mon, Mar 17, 2014 at 4:50 PM, Joey Schorr  wrote:

> The intention was to both deobfuscate stack traces and provide a way for
> de-minimization of source code if the mapping was semi-direct. The old
> Closure Inspector ( would
> actually use the names to remap the source code view inline, but this
> obviously only applied to the Closure case where the input language was
> also (basically) JavaScript.
> On Mon, Mar 17, 2014 at 7:41 PM, Brian Slesinsky wrote:
>> (Sending this to the list since I can't comment directly on the document.)
>> Re:
>> A comment on this line:
>>   Line 7: A list of symbol names used by the “mappings” entry.
>> I think the spec should explain a bit more about how this is typically
>> used. Despite doing a fair amount of work with sourcemaps, I was unclear
>> on
>> this until recently.
>> As far as I know no debugger uses the "names" field, but the intention is
>> to deobfuscate stack traces. That is, when a JavaScript exception occurs
>> or
>> a debugger stops at a breakpoint, we can treat the stack trace as a list
>> of
>> positions in JavaScript files. For each position, the "name" is the
>> deobfuscated function name that should appear in the stack trace. (Or more
>> generally, it is whatever string would most usefully appear in the
>> function
>> name position when displaying a stack frame in the debugger.)
>> - Brian
>> _______________________________________________
>> dev-js-sourcemap mailing list