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

Expose import map shim on JS API #9

Closed
josh-sachs opened this issue Mar 26, 2019 · 3 comments · Fixed by #17
Closed

Expose import map shim on JS API #9

josh-sachs opened this issue Mar 26, 2019 · 3 comments · Fixed by #17

Comments

@josh-sachs
Copy link

Currently, shim only supports defining import maps via dom.

<script type="importmap-shim">

We can src or inline the map, but there is a hard constraint on the existence of this element in the dom.

Would be nice to be able to use the shim in a web worker (which doesn't have a dom).

Basically, import the shim into a webworker and call something like useMap(url|object)

I understand the shim is trying to force a pattern as close to the final spec as possible... maybe the lib could detect it is in a webworker before defining/exposing the function? Or throw an exception if used on the main thread.

Happy to discuss further...

@guybedford
Copy link
Owner

guybedford commented Mar 27, 2019

So ideally we should position this project to roughly where things are headed.

One thing we could consider here is extending the shim to the worker constructor itself.

For example, new WorkerShim('./path/to/module.js', { type: 'module', importMap: {...} }) or similar. I think we should make the type: 'module' mandatory too so that without it, a normal worker is created, that could also still access the dynamic import through import() being rewritten. That way window.Worker = WorkerShim could be a comprehensive polyfill.

This would line up with the current strawman at WICG/import-maps#2.

Basically the WorkerShim constructor would just be a worker wrapper that contained eg the code:

importScripts('/path/to/es-module-shims.js');
_importMap = {...};
importShim('/path/to/worker.js');

where the generated code above would run in a blob or data URL. (Workers work with data / blob right?).

Definitely sounds like useful directions.

@jbanety
Copy link

jbanety commented May 15, 2019

Hi,
Exposing utility functions could be usefull for dynamic import of different applications in a microservice environnement.
So i can have several importmaps json files with specific dependencies for each application.

@guybedford
Copy link
Owner

We can support multiple import maps today, although how deferred import maps load is not yet specified. I've created #15 to track this.

The loading process for workers should be more like the approach above though I think.

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