Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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)

enter image description here

like image 409
meow Avatar asked Feb 03 '17 03:02

meow


People also ask

Why doesn’t import * work at function scope?

Why doesn’t import * work at function scope? Python is a regular language, which means that function definitions, class definitions, import statements etc. mostly work at any scope. But there’s an exception for “ from ... import * “, which can’t be used inside a function.

Are imported variable bindings difficult to debug?

Imported variable bindings have difficult to debug names. · Issue #3957 · webpack/webpack · GitHub Could one use static-analysis to check for happy-case no export redefinition?

What happens when you import a module at global scope?

When you import a module at global scope, Python creates a new entry in the global dict with the name of the module you just imported (or its alias if you did an import ... as ... ). When you do from foo import *, something slightly more complicated happens.

Can I call a variable from an imported module in main?

In main, you can call a variable defined in one of your imported modules, but not the other way around. In python, an imported module should be able to function as stand-alone scripts.


1 Answers

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.

Visualization of source maps

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

Visualization of the compiled code

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?

like image 129
henk Avatar answered Oct 22 '22 20:10

henk