Skip to content

Support import maps in workers#10858

Draft
nicolo-ribaudo wants to merge 2 commits intowhatwg:mainfrom
nicolo-ribaudo:workers-import-maps
Draft

Support import maps in workers#10858
nicolo-ribaudo wants to merge 2 commits intowhatwg:mainfrom
nicolo-ribaudo:workers-import-maps

Conversation

@nicolo-ribaudo
Copy link
Copy Markdown
Collaborator

@nicolo-ribaudo nicolo-ribaudo commented Dec 12, 2024

This patch started as a conversation with @guybedford. I tried writing some spec for one of the potential approaches discussed in WICG/import-maps#2.

This PR is not actually ready as I have not finished reading all the discussions about the topic and I haven't talked with any implementation, but it's better to leave it here as a draft in case somebody is interested than just keeping it hidden in a branch :)

There are two commits: one that allows workers to inherit the import map from their creator (which probably will be the most common use case?), and one that allows to explicitly pass an import map object. The two commits don't conceptually depend on each other, so it would also be ok to decide to only do one of them.

This patch does not support import maps for SharedWorker, but thanks to the work done in #10528 it would be possible to support them: when a page connects to an existing shared worker, the shared worker's import map can get "updated" with the new one. Generally import maps in multiple pages of a same application match in their intersection, so this would probably give a good behavior (the alternative is to throw when passing an import map that is different from the existing one).

This approach does not work for ServiceWorker, and they would likely need a completely different solution (such as the HTTP-header based ones that were suggested in WICG/import-maps#2).


  • At least two implementers are interested (and none opposed):
  • Tests are written and can be reviewed and commented upon at:
  • Implementation bugs are filed:
    • Chromium: …
    • Gecko: …
    • WebKit: …
    • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
    • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
  • Corresponding HTML AAM & ARIA in HTML issues & PRs:
  • MDN issue is filed: …
  • The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)


/infrastructure.html ( diff )
/webappapis.html ( diff )
/workers.html ( diff )

This option adds an `importMap: "none" | "clone"` option to the `Worker`
constructor, which defaults to `"none"`. When this option is set to
`"clone"`, the `Worker` constructor will take a snapshot of the current
import map and use it as the import map inside the worker.

Passing the `importMap` option to `SharedWorker` is an error, to make it
possible to give it a meaning in the future.
This commit allows passing a JavaScript object to `Worker`'s `importMap`
option, which is validated and used as the worker's import map.

The existing validation of the JSON import map has been delegated to
WebIDL, so that it can be re-used for this option's value.
@WebReflection

This comment was marked as spam.

@LeaVerou
Copy link
Copy Markdown
Member

There are two commits: one that allows workers to inherit the import map from their creator (which probably will be the most common use case?), and one that allows to explicitly pass an import map object. The two commits don't conceptually depend on each other, so it would also be ok to decide to only do one of them.

I wonder, would it help make progress faster if these were separate PRs?

@nicolo-ribaudo
Copy link
Copy Markdown
Collaborator Author

nicolo-ribaudo commented Jan 23, 2026

The reason this PR is stalled at the moment is only that I don't have work time to push for it. If there is implementations interest I'm happy to finish the spec work, but otherwise I'm not going to go around advocating for the feature 😅

(if anybody wants me to have work time to push for it, you can find my email in my GitHub profile!)

@WebReflection
Copy link
Copy Markdown
Contributor

WebReflection commented Jan 23, 2026

I don't know how useful is this but I needed this too so here my workaround which worked pretty well:

  • I register a service worker that receives the importmap resolved from the main thread
  • anything that fetches one of those entries from either main or workers will trigger a whole canonical (absolute) URL
  • the Service Worker at that point decides what to do:
    • is the requested URL in the importmap? Return the fetch of its counterpart instead
    • was it not? do nothing or do whatever the rest of the fetch logic was supposed to do
  • this workaround abuses the network stack from both main and workers, yet it worked fairly well to me

The end ... if anyone needs this workaround, happy to help👋

edit P.S. I can generate the entirety of the network graph with CLI but I haven't published that yet, you'll be informed once that's out as it helps smoothing out a lot of burden for related topics

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

addition/proposal New features or enhancements topic: imports/exports Import maps, specifiers, imports, exports topic: script topic: workers

Development

Successfully merging this pull request may close these issues.

4 participants