-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Thanks for making this library! I've been testing it out for some use cases with anywidget. I'm trying to understand the importmap "scope" that users have access to if allowing them to declare an import map. At the moment, it seems that if an import for a bare specifier has been declared, subsequent dynamic imports with an alternative import map are ignored.
In this example, I would expect foo1 to be { yay: "it works" } and foo2 to be the actual React, but foo is resolved to ./react.js in either case. If I flip the imports (e.g., load foo2 first), the both are resolved to React.
<!DOCTYPE html>
<script type="module">
import { importWithMap } from "https://unpkg.com/dynamic-importmap@0.1.0";
const foo1 = await importWithMap("./foo.js", {
imports: { react: "./react.js" },
});
console.log({ ...foo1 });
// { yay: "it works!" }
const foo2 = await importWithMap("./foo.js", {
imports: { react: "https://esm.sh/react@latest" },
});
console.log({ ...foo2 });
// { yay: "it works!" }
</script>// ./foo.js
export * from "react";// ./react.js
export const yay = "it works!";Do you know if it is possible (or within scope) to manage this type of use case? I think it would be quite powerful for "bits" of an application to define their own dependencies (without polluting others).
For anywidget, I'm imaging a use case where each widget can define an importMap, and then I can load the widget ESM with something like:
const anywidget_importmap = { ... };
const widget = await importWithMap(esm, merge(anywidget_importmap, widget_importmap))