From:  Ron Buckton <>
Date:  29 Aug 2015 06:54:21 Hong Kong Time

Re: Proposal for encoding source-level environment information



I'm just now looking at your proposal. Can you take a look at, which we have discussed previously on this list, to see whether this proposal has any similarities or differences that would make it an improvement over the proposal that Andy Sterland and I put together? Our original proposal stalled due to the fact it did not solve mapping renamed or minified properties of an object.


From: dev-js-sourcemap  on behalf of Nick Fitzgerald 
Sent: Friday, August 28, 2015 9:39 AM
To: Brian Slesinsky
Cc: dev-js-sourcemap (
Subject: Re: Proposal for encoding source-level environment information

Hi Brian,

The data encoded in the "env" string is the source-language's lexical scope
tree. Each scope has a start and end location, a type (function or block),
and a set of bindings. Each binding has a name, type (local, parameter, or
constant), and its value's location (expressed as a snippet of JS that can
be evaluated to retrieve the value).

Care has been taken to ensure that the format is future-extensible so that
we can add new scope types / binding properties / etc in the future. I just
started with what I saw as the basics.

On Tue, Aug 25, 2015 at 5:12 PM, Brian Slesinsky 

> I skimmed but I'm not really following in detail. I wonder if it would
> make sense to define a mapping between the compressed  "env" data structure
> and a JSON format, and give a few examples? Then we can discuss what data
> goes into it separately from how it gets compressed.
> - Brian
> On Tue, Aug 25, 2015 at 4:37 PM, Nick Fitzgerald 
> wrote:
>> Hi folks,
>> I'd like to embed some information about the source-level lexical
>> environment within the source map format, so that it can take its first
>> baby steps towards being a Real Debugging Format(tm).
>> This will enable:
>> 1. Debuggers to rematerialize the source-level environment
>> ​,
>>  scopes
>> ​,​
>> and their bindings (regardless if there are corresponding scopes and
>> bindings in the generated JS).
>> 2. Debuggers to locate a binding's current value. This includes situations
>> where:
>>   * The binding was renamed in the compiled JS. For example, the binding
>> is
>> named
>> ​`​
>> atom?
>> ​`​
>> in the original source and renamed to
>> ​`​
>> atom_question
>> ​`​
>> in the compiled JavaScript. Or a minifier renames
>> ​`​
>> getLatestFooWidget
>> ​`​
>> to
>> ​`
>> aF
>> ​`​
>> .
>>   * The binding does not have a corresponding binding in the compiled
>> JavaScript. For example, the compiler inlined the binding's value after
>> recognizing that the binding was never mutated.
>> Here is the proposal, for your consideration:
>> Feel free to discuss it on this list or on the source-map-rfc pull
>> request:
>> Cheers,
>> Nick
>> _______________________________________________
>> dev-js-sourcemap mailing list
dev-js-sourcemap mailing list