Could you try removing the workaround? After an initial failure, I can’t seem to replicate the problem anymore. (Perhaps a caching issue?)
Edit: Ah, there it is again, after removing and adding back the import in a new cell.
Edit 2: I can’t reliably reproduce the error. Still recommending to remove the workaround, for easier investigation.
Oh, you’re right, it only occurs if the cache is deactivated, or if it’s the cache is empty (some request has still not been cached). Reloading the page with the cache activated removes the error.
So: we still need to understand why it fails on the first visit.
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.
Thanks a lot for the detailed answer, it’s very useful, and I could reproduce the process.
Do you know if the developer tools provide a way to search for a string (“invalid module” in our case) in all the sources, or is it necessary to open every file then search in it?
Yes, that is the “search drawer” to which I was referring in point 2:
in your developer tools, open the “Search” drawer and search for “invalid module” (it should appear in two files)
The “drawer” is the section at the bottom with the JS console, that can be toggled (hence “drawer”). You can add the search tab via the dot menu to the left:
Firefox also lets you search across all files. If you’re on macOS though, make sure that you’re in the debugger panel. Otherwise you’ll just toggle fullscreen.
I made a tweak to my notebook so that importCell passes through the existing require function, rather than loading a new one.
// Instantiate a new runtime, but reuse the existing runtime’s require.
// (This is ensures that any requires in imports still work.)
const library = Object.assign(new Library(), {require: () => require});
const runtime = new Runtime(library);
That seems to have fixed the problem. Thanks for doing all the legwork!
for that with cache disabled)
. I will use Chromium the next time I have to do hardcore debugging