Skip to content

Global scope / overrides? #5

@manzt

Description

@manzt

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))

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions