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:
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?
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
.
Looks like it's been addressed and will become available in the next Chromium update
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.