Imported variable works but is not defined when accessed in debugger (within same scope)

Question

I am using webpack + es6 to build my files. I exported modules in a Math.js, then imported in Main.js.

In the latter, I used the module to compute, then set a stop in the debugger. The former worked but it was not defined when I tried to use it in the console.

The scope is the same - why would the module not be defined in the console?

// Math.js
export function sum(x, y) {
  return x + y;
}
export var pi = 3.141593;

// Main.js
import * as mathTest from "./Math.js";
console.log("2π = " + mathTest.sum(mathTest.pi, mathTest.pi));
debugger

// Output
// The statement from the file writes properly but the debugger fails (but <this> is the same)

Halfon

I've noticed this. Don't understand the "why" behind this behavior. But if you just assign your import to a variable you'll be able to use it in the debugger console. – Stakeout

hi tom, thanks a lot! good to know i am not crazy - i was thinking my import failed since the debugger did not show it. Do you mind answering it with the code for assignment and i can accept it? – Halfon

Are your scripts being minified at all? It might look ok due to source maps but the variable in question may actually be something like m – Intenerate

I am running in npm run dev. all other variables are not minified – Halfon

Are you using Babel or compiling the modules with Webpack 2? If you're using Webpack 2, it probably just renames the variable to something else, and your sourcemaps are hiding that fact from you. – Mellar

i am using babel w webpack2 as the loader. i am running in npm run dev - would it still rename it? – Halfon

I dont think it does - i looked at the source code - it is not minified – Halfon

I think the problem is that v8 makes some optmizations, so the debugger runs faster. It includes not computing some "unused" variables. Please refer to this post: #28389030 – Gem

Try to change the order of exports. It may be because pi is defined after sum, just a wild guess though... – Higinbotham

Answer 1

Though might be late for the op, this is still a valid problem.

While it might look like you are debugging the code that you have written, that is simply not the case.

The reason is that your code was minified and uglified by webpack (and probably transpiled by babel). The compiled code is what gets executed by the browser, which then maps it through source maps to your source code.

Browsers do their best to make this experience as seamless as possible. In most cases, you won't even notice the illusion but in other cases, it might confuse you. Since the variables and module imports are renamed during the uglification process, they are no longer available by their original name in the console.

So in order to find out the value of an imported module, you would have to observe the compiled variable.

As of 2021, you get great assistance from your browser for that purpose. As you can see in the following picture, while Thing would be undefined, _Thing would give you the expected result and is even proposed by the autocompletion.

Also, pay attention to the [sm] in App.js[sm], it indicates that you are observing the source maps version and not the executed code.

Alternatively, we could observe the compiled/executed code, and verify that the Thing was imported as _Thing.

Related and often experienced issues:

• The debugger is not able to stop at the desired breakpoint.
• Lines not available for breakpoints in the debugger.
• And console errors pointing to the uglified code.

If you desire to understand the reason, dive deeper into source maps: How do source maps work?

Respectable