RFC: Consistent source mapped variables in Chrome DevTools

[Meysamsarabadani]

Author: Simon Zünd (@szuend), Jecelyn Yeen (@jecfish), Meysam Sarabadani (@Meysamsarabadani)
Posted: Aug 14, 2023
Status: Open
Chrome bug tracker: https://crbug.com/1470177

The goal of this RFC is to validate the design with the community, solicit feedback on open questions and identify bugs or edge cases that negatively impact the debugging experience.

Complete: This RFC is now complete. See a summary here.

Motivation

DevTools uses source maps to help you debug web applications with your original code.

The latest improvement in this RFC aims to further improve the debugging experience by allowing you to evaluate your original variable names consistently across DevTools, such as the Console, conditional breakpoints & logpoints, Watch expressions, Live expressions and more.

Background

Let’s look at this example, given the following code:

// your original TypeScript code
const coffee = 'coffee name';
const price = '88 Euro';
const text = `The ${coffee} costs ${price}.`;

After your build process, your code will be compressed into one line, together with a source map file, and this is the final output the browser actually reads.

// The final one-line compressed JavaScript code that the browser reads
const o = "coffee name", n = 88, t = `The ${o} costs ${n}.`;

During debugging, instead of showing you o in the inline preview and Scope pane, DevTools tries to use source maps to interpret and show you your original variable name coffee.

The Scope pane in the Sources panel shows original variable names instead of the minified ones. The inline preview shows correctly as well.

This is great, but DevTools did not consistently apply source maps in every place previously. For example, typing coffee in the Console throws an error, but o returns the correct value. Ideally, both should work. This RFC aims to improve this experience across all parts in DevTools.

Evaluating the original variable name throws an error in the Console, but evaluating the minified variable name successfully returns value.

Goals

• Allowing you to evaluate your original variable names consistently in the following areas:
  • Expressions in the Console (including autocomplete suggestions)
  • Live expressions
  • Watch expressions
  • Conditional breakpoints and Logpoints
  • Scope pane (already works prior to this RFC)
  • Inline preview in the Sources panel (already works prior to this RFC)
• Allowing you to evaluate your original variable names regardless of which JavaScript frameworks and build tools you are using.

Non-goals

We don’t aim at fixing existing source maps issues with this RFC. For example:

• Missing variables. DevTools cannot evaluate variables that are not defined in the source maps (e.g. variables that are optimized away during the build process)
• Minified properties. Resolving minified properties of an object is out of scope in this RFC (e.g. coffee.name has been renamed to coffee.n).
• Private class members, Resolving minified private class members is out of scope as well. (see [crbug.com/1470176](https://crbug.com/1470176))

Try out the prototype

The prototype is available from Chrome 117 onwards. In Devtools, click on the Settings icon > Experiments tab > enable the Resolve variable names in expressions using source maps experiment.

To check your current browser version, type chrome://version in your address bar (Install Chrome Beta, Dev, or Canary if your current browser version is lower.)

Evaluate original variable names across DevTools

The examples shown in the screenshots below are from the demo web page. You can first try out the prototype on the demo web page, and then try it out in your own applications.

The Console

Before: Evaluating coffee in the Console returns an error.
After: Evaluating coffee in the Console returns its value.

Watch expressions

Before: Evaluating coffee in the Console returns no value. price variable is not shown in the auto-complete suggestion.
After: Evaluating coffee in the Console returns its value. price variable is listed in the auto-complete suggestion.

Logpoints & conditional breakpoints

Before: Evaluating coffee in the logpoints and conditional breakpoints returns errors.
After: Evaluating coffee in the logpoints and conditional breakpoints returns its value.

Live expressions

Before: Evaluating coffee in the live expressions returns errors.
After: Evaluating coffee in the live expressions returns its value.

Expression preview in the editor

Before: Hover over coffee in the expression returns function.
After: Hover over coffee in the expression returns its value.

⚠️ Attention: Potentially not what you expect

What we’ve showcased so far are presumably positive changes. However, there are some scenarios where it might not work as you expect. We would like to get your feedback on these scenarios.

Evaluate minified variables works as well

With the latest changes, you can evaluate both original and minified variables.

For example,

Before: Evaluating coffee in the Console returns error, and o returns Coffee Latte .
After: Evaluating coffee and o in the Console returnsCoffee Latte.

There are chances of naming collisions (e.g. you have both original z and minified z variables). In case of naming collisions, DevTools will use the original variables.

No preview for expressions involve minified property names

This scenario only happens if you use advanced minification features like minify property names. You don’t use that usually because most build tools don’t enable that by default.

Let’s take a look at this demo that mangle property and function names. Observe the minified index..js file.

Here are some highlights in this demo,

• The getRandomCoffee(magicNumber) function (line 1) is mangled into c(t).
• The coffeeList array at line 2 becomes [{e:'Espresso'},...,{e:'Latte'}]. The property name is minified to e .

What happens if you hover over line 7 at getRandomCoffee(magicNumber).

Before: The debugger doesn’t fully evaluate the expression. It just shows you the minified function signature c(t) .

After: The debugger attempts to evaluate the expression. However, since the debugger doesn’t support minified property names, it will show the object with minified property e:'Latte' instead of name:'Latte'.

How about hovering over getRandomCoffee(magicNumber).name.

Before: The debugger doesn’t attempt to evaluate expressions. It just shows you the minified function signature.
After: The debugger tries to evaluate the expressions. However, since the debugger doesn’t support minified property names, it will show minified undefined. There’s no name property on the resulting object. To see the coffee name, try evaluate getRandomCoffee(magicNumber).e in the Console instead.

FAQ

1. Why sometimes evaluating variables doesn’t work?
   It is not a bug. Unfortunately, DevTools cannot evaluate variables that are not defined in the source maps. In our example, the variable endText is completely optimized away during the build process. Therefore, DevTools doesn’t have the information to map it.

As mentioned in the non-goals section, this RFC doesn't aim at fixing existing source maps issues. Therefore, minified properties and private class members aren’t in the scope of this project either.

Questions for Discussion

In addition to general feedback, we would like to collect feedback on the following specific questions:

1. Does the prototype work correctly for your app/site? The JavaScript ecosystem is very heterogeneous. We are interested in any case where the prototype either doesn’t work or gets it wrong.

2. Is it intuitive to use original variable names? This prototype added original variable names in the autocomplete. You can also evaluate both original and minified variables (e.g. coffee and o) with DevTools. Is this intuitive enough?

3. Is this feature helpful for you? Does this feature make it quicker for you to debug and pinpoint your issues?

4. Is this feature confusing to use? Since we support both original and minified variables (e.g. coffee and o), do you feel that is confusing?

5. Should the debugger support only original variables? When do you see yourself using the minified variables?

6. In the case of naming collisions the debugger prefers original variables over minified variables. Does this align with your expectations?

[samdenty]

This is an awesome feature! This was mainly why I disabled sourcemaps, because of this issue.

The only other real issue I have with debugging unrelated to sourcemaps, but in a similar area is:

Sometimes when I'm debugging and I go up the stack frame tree, some variables are not defined in the debugger even though they are defined in the code. Or another issue is some variables with the same name, when going up the stack frame reference only the most recent one

[szuend]

For the first issue "some variables are not defined in the debugger even though they are defined in the code". Would you be able to provide me with a concrete example? We know that some minifiers inline variables if they only have one one use-site. Are you referring to that?

For the second issue "some variables with the same name": Are you referring to variable shadowing in the scope chain? For example:

function someFn(arg) {
  const x = 42;
  if (arg) {
    const x = 12;
    debugger;
  }
}

Pausing on the debugger statement makes the outer 'x' unavailable in the console (it's still modifiable from the scope view). Or do you mean something else?

[jecfish]

After several weeks of discussion, the RFC for Consistent source mapped variables is now closed. While the comments seems inactive here, we received over 100 feedbacks in other channels (Twitter, Mastodon, LinkedIn, surveys, in person).

We are very happy that the overall feedback has been positive and devs see consistent source mapped variables as a useful feature to have. Based on the feedback and the initial prototype, we plan to move forward with the proposed design.

We’ll provide more updates as we progress with the implementation and incorporate your feedback, so stay tuned! In particular, this action item stand out:

• Show visual indicator (https://crbug/1495264) for original and minified variables. Devs feel confuse about being able to evaluate both original and minified variables in the Console.

Thanks to all the participants for your help evolving Chrome DevTools!