49

Working on building JavaScript sourcemaps into my workflow and I've been looking for some documentation on a particular part of debugging source maps. In the picture below I'm running compressed Javascript code, but through the magic of source maps Chrome debugger was able to reconstruct the seemingly uncompressed code for me to debug:

Source Maps

However, if you look at the local variables, someNumber and someOtherNumber are not defined. Instead, we have a and r, which are the compiled variable names for this function. This is the same for both Mozilla Firefox and Chrome.

I tried looking through the Chrome DevTools Documentation on sourcemaps, but I didn't see anything written about this. Is it a current limitation of sourcemap debugging and are there any workarounds for this?

update:

I've since found this thread in chromium project issues. It doesn't look like it has been or is being implemented. This is becoming an increasingly more important problem as teams are beginning to implement Babel in their build systems to write ES2015 code. Have any teams found a way around this?

Dan-Nolan
  • 6,594
  • 4
  • 27
  • 32
  • Can you provide files to test locally? – Cheery Oct 14 '14 at 22:16
  • 1
    Here's an example of a site using source maps: http://dev.fontdragr.com/ You should be able to put a breakpoint in any of the JavaScript source file functions and replicate the behavior. – Dan-Nolan Oct 15 '14 at 03:26
  • 1
    I have the same problem. It seems like Chrome really doesn't support variables mapping for now. – Andrew Kovalenko Jul 24 '15 at 20:50
  • 7
    It is pretty amazing that this hasn't made it into Chrome yet. It used to be an annoyance, but with complex build processes and ES6 module transpilation, you can have name mangling even in unminified code. – Jamie Treworgy Aug 12 '15 at 18:39
  • 1
    @syarul - I don't think you've understood the purpose of source maps. Source maps and automated testing is not mutually exclusive. – jBoive Mar 14 '16 at 20:00
  • @jBoive forget my comment, that's not going to solve this issue anyway, I haven't stumble upon this yet, as soon I made discovery maybe I can clear thing of better – syarul Mar 15 '16 at 13:49

3 Answers3

3

Using Watch Expressions on the right hand side, usually solves this. Expand the menu, and use the plus button to add your variables. You can use someNumber and someOtherNumber, and even someNumber + someOtherNumber.

Selfish
  • 6,023
  • 4
  • 44
  • 63
2

Looks like it's been addressed and will become available in the next Chromium update

Dan-Nolan
  • 6,594
  • 4
  • 27
  • 32
1

There's still no solution to mapping variable names in Javascript source maps, but there's a solution for Babel 6. As we've adopted ES2015, the mangled import names became a major pain point during development. So I created an alternative to the CommonJS module transform that does not change the import names called babel-plugin-transform-es2015-modules-commonjs-simple.

As long as you aren't writing modules that depend on exporting dynamic bindings it is a drop-in replacement for the default babel commonjs module transform:

npm install --save-dev babel-plugin-transform-es2015-modules-commonjs-simple

and .babelrc:

"plugins": ["transform-es2015-modules-commonjs-simple"]

This will compile ES2015 modules to CommonJS without changing any of the symbol names of imported modules. Caveats are described in the readme.

This won't help you with minifying/uglifying, though, so the best solution seems to be to just don't use minification during development. Then at least it's only a problem if you have to debug something on a production web site.

Jamie Treworgy
  • 23,934
  • 8
  • 76
  • 119