Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global scope / overrides? #5

Open
manzt opened this issue Aug 15, 2023 · 2 comments
Open

Global scope / overrides? #5

manzt opened this issue Aug 15, 2023 · 2 comments

Comments

@manzt
Copy link

manzt commented Aug 15, 2023

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))
@manzt
Copy link
Author

manzt commented Aug 15, 2023

Side note, I just learned that importmaps work for data urls! Really cool.

<!DOCTYPE html>
<script type="importmap">
  {
    "imports": {
      "bar": "data:text/javascript,export const BAR = \"BAR\";"
    }
  }
</script>
<script type="module">
  import * as bar from "bar";
  console.log(bar.BAR);
  // "BAR"
</script>

@keller-mark
Copy link
Owner

It seems like this is a bug. es-module-shims supports this with a mapOverrides option https://github.com/guybedford/es-module-shims#overriding-import-map-entries which I modified to always be true here

const mapOverrides = true;

I think it should first be fixed, but ideally it could also be configured as an option like

const options = { mapOverrides: true };
const foo1 = await importWithMap("./foo.js", importMap, options);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants