-
-
Notifications
You must be signed in to change notification settings - Fork 83
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
Comments
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, This would line up with the current strawman at WICG/import-maps#2. Basically the 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. |
Hi, |
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. |
Currently, shim only supports defining import maps via dom.
<script type="importmap-shim">
We can
src
orinline
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...
The text was updated successfully, but these errors were encountered: