Inject require

[mootari]

A fundamental limitation of d3-require in the context of Observable is that there can only be one require instance, because each instance needs to register its window.define.

There is currently no way to load a separate Runtime with an existing require instance without redefining the entire stdlib surface.

Why is this a problem?

Notebook imports within Observable are static imports, meaning that the module files will be loaded even if no cell uses them. Very often notebooks load additional utilities to enhance their documentation. These dependencies are usually not required to use a notebook's core exports.

As a workaround, a notebook dependency can be instantiated lazily through a second Runtime instance. However, this fails if the notebook contains any require calls, as the Runtime will load its own Library instance and require instance.

[mootari]

Example of a fragile solution within the current limitations:

async function lazyImport(slug, cells, builtins) {
  const [{Runtime}, {default: define}] = await Promise.all([
    import('https://cdn.jsdelivr.net/npm/@observablehq/runtime/dist/runtime.js'),
    import(`https://api.observablehq.com/${slug}.js?v=3`)
  ]);
  const map = (o, fn) => Object.fromEntries(Object.entries(o).map(fn));
  let _builtins;
  if(builtins) _builtins = map(builtins, ([n, v]) => [n, () => v]);
  const module = new Runtime(_builtins).module(define);
  return Object.fromEntries(
    await Promise.all(cells.map((n) => module.value(n).then((v) => [n, v])))
  );
}

signature = (await lazyImport(
  '@mootari/signature',
  ['signature'],
  {require, html, DOM, md, Generators}
)).signature

[mootari]

Simplified test case that shows the symptoms (may require loading with an empty cache):

[mbostock]

I’ve added the ability to set the default require in #289. I’m not really sure there is anything else we can do here given the fundamental nature of AMD depending on a define global.

As for lazy imports, a big plus one! I have them working, but ran into a snag with import-with which will likely require making module.derive async. I’m hoping to revisit that again in the near future (though there is a lot on my plate so no guarantees as to when that will happen). That is covered by observablehq/feedback#74.

For anyone reading this, I recommend against writing your own implementation of import as shown above, as it is easy to introduce race conditions that cause errors with transitive imports.