The process was:
- verify that you can reliably reproduce the error (
for that with cache disabled) - in your developer tools, open the āSearchā drawer and search for āinvalid moduleā (it should appear in two files)
- prettify each file and set a breakpoint in the corresponding line (you may have to search the file for āinvalid moduleā)
- reload, and wait for the breakpoint to hit
From here on we have two objectives:
- find out where the error originated
- find out the nature (and possibly the cause) of the error
The first can be done fairly easily by looking through the call stack, but finding the right place requires some intuition. In the screenshot below we find the notebook cell that the error originated from:
The second point on the other hand is a lot messier, especially when working with minified code. In order to orient yourself, youāll want to have some unminified reference code at hand. Here is the one for d3-require.
By relating the minified code with the reference code, we find the line where we had set our breakpoint.
Now we jump back to the top of the call stack, collapse it, and take a closer look at the scope below it:
On the right side, we see the actual error message. By hovering over the variable āCeā we can inspect its contents, and conclude that Ce.pop()returned undefinedbecause the array is empty. Looking the ref. source, we related Ce to queue.
From here on it gets somewhat handwavy. We can set additional breakpoints for Ce.push and Ce.pop in order to poke around in the values that pass through. Doing so (and inspecting both anonymous function bodies and surrounding scope), we discover that thereās another d3 instance which gets loaded successfully.
When youāve messed around with d3-require in the past, you may have noticed that it caches resolved modules, and also sets some global variables (an unfortunate requirement of the AMD format).
Tip: Itās good to keep in mind that you can interact with the active breakpointās scope in the JS console.