User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

Steps to reproduce:

Import maps currently have to load before any ES module and there can only be a single import map per document. That makes them fragile and potentially slow to use in real-life scenarios: Any module that loads before them breaks the entire app, and in apps with many modules the become a large blocking resource, as the entire map for all possible modules needs to load first.

There's a proposal [1] to enable multiple import maps per document, by merging them in a consistent and deterministic way.

Mozilla standard position - https://github.com/mozilla/standards-positions/issues/1058

[1] https://github.com/whatwg/html/pull/10528

Needinfo'ing Yoshi, as he's our expert for Import Maps

Yoshi: Not sure about your GitHub handle but you probably want to take a look at the proposal and give it some thought about implementation challenge.

The related MDN page already mentions multiple import maps, so there's probably no updated needed for that. Though this should be reflected in the related browser compat data.

Sebastian

Is 'Multiple import maps' supported by Firefox or not? If it is, then it is should updated in browser compat data.

Checking the code, Firefox is still sending an error message when we try to use multiple importmaps:

https://searchfox.org/mozilla-central/rev/a589ce1e3ff122d53690f101780a3b4747946d71/dom/script/ScriptLoader.cpp#1550
https://searchfox.org/mozilla-central/rev/a589ce1e3ff122d53690f101780a3b4747946d71/dom/locales/en-US/chrome/dom/dom.properties#371

Note that the code above also prevents to process import maps after a previous module import, which Yoav's PR changed too

A Document can have multiple import maps processed, which can happen either before or after any modules have been imported,

(note: I found this while writing tests for Trusted Types at https://phabricator.services.mozilla.com/D251456)

(In reply to [:anutrix] from comment #3)
Multiple import maps are not supported yet.

(In reply to Jon Coppeard (:jonco) (PTO until Friday 13th June) from comment #5)

(In reply to [:anutrix] from comment #3)
Multiple import maps are not supported yet.

Is there a PR out for multiple import maps on Firefox? Or otherwise any details on release date?

The compatibility gap with Firefox on this one is starting to grow - https://caniuse.com/mdn-html_elements_script_type_importmap_multiple_import_maps.

While we do have ES Module Shims polyfill to fill the gap, it would be a huge benefit to have these modern import maps workflows working natively.

(In reply to guybedford from comment #7)

The compatibility gap with Firefox on this one is starting to grow - https://caniuse.com/mdn-html_elements_script_type_importmap_multiple_import_maps.

While we do have ES Module Shims polyfill to fill the gap, it would be a huge benefit to have these modern import maps workflows working natively.

Can you elaborate on the huge benefit? It can help in getting the work prioritized.

Here's the article on the feature here being used by Shopify - https://shopify.engineering/resilient-import-maps.

Currently they use the polyfill to support older browsers - https://github.com/guybedford/es-module-shims, which is slower and less efficient than native.

Are there more details on the performance costs of the polyfill? (I've only skimmed the article so may have missed it)

The polyfill re-executes all modules using source text rewriting and blog URLs, effectively re-handling the entire module system. It's typically 1.5-2x slower than native modules to execute a module graph.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #8)

(In reply to guybedford from comment #7)

The compatibility gap with Firefox on this one is starting to grow - https://caniuse.com/mdn-html_elements_script_type_importmap_multiple_import_maps.

While we do have ES Module Shims polyfill to fill the gap, it would be a huge benefit to have these modern import maps workflows working natively.

Can you elaborate on the huge benefit? It can help in getting the work prioritized.

I have a site that relies on import maps and won't work without them. The problem is that if users have extensions that inject import maps or modules before the site's, it'll break the page for some fraction of users and there's nothing we can do about it. Supporting multiple import maps is necessary for robustness vs. misbehaving extensions. Currently the site is working fine in browsers that support that, but Firefox is left behind.

Implement https://html.spec.whatwg.org/#resolved-module-set
and store it in ModuleLoaderBase

This is to simplify ImportMap::ResolveModuleSpecifier, so we just need
to pass baseURL to it.

This is just a minor update to the latest spec, the logic remains the same.

Before:
If found a match in scopesImportMatch, return result.

After:
If found a match in scopesImportMatch, break from the for-loop.
if result is not null, return result

Added AddToResolvedModuleSet to complete the 'resolve a module specifier'.

Add a request parameter to construct the ReportWarningHelper.

Implement https://html.spec.whatwg.org/#merge-existing-and-new-import-maps

During preload, module resolution may be incomplete because import map
information is not yet available. To handle this, store the resolved
module set within the module script itself.

Later, when the preloaded request is reused during parsing, merge the
preloaded resolved module set into the global resolved module set to
ensure consistency.

When registering an import map, we must remove any preloaded scripts
because their resolved URLs may no longer be valid under the new import
map.

If top-level module scripts have already been preloaded, we also clear
the [[LoadedModules]] slot in the ModuleObject, as well as the
[ParseError] and [ErrorToRethrow] fields in the module scripts. This
ensures that when these modules are fetched again, the entries in
mFetchedModules do not reuse stale preload data.

For entries in mFetchingModules, we verify whether each module’s
resolution remains consistent after merging the import map. If a
resolution no longer matches, the ongoing (preload) fetch request is
canceled.

We take no action on mFetchedModules entries because we cannot determine
whether their associated scripts were fetched before or after the import
map registration.

Updating the tests with multiple import maps.

Even with a 0.5-second delay, preloading causes the module script to
arrive before the import map. Increase the delay to guarantee the import
map is available before module execution.

FYI, there are a couple of trusted type tests that had to place import map before a module load: https://searchfox.org/firefox-main/search?q=1916277&path=testing%2Fweb-platform%2Ftests&case=false&regexp=false ; I don't know if that improved with your patches, but it would be nice to check if putting import map load after module load works and remove these comments from WPT.

Do we have a WPT test that actually checks whether import map load is possible after a module load? Probably we should add one in /import-maps

Add multiple import maps into /trusted-types

(In reply to Frédéric Wang (:fredw) from comment #28)

FYI, there are a couple of trusted type tests that had to place import map before a module load: https://searchfox.org/firefox-main/search?q=1916277&path=testing%2Fweb-platform%2Ftests&case=false&regexp=false ; I don't know if that improved with your patches, but it would be nice to check if putting import map load after module load works and remove these comments from WPT.

Do we have a WPT test that actually checks whether import map load is possible after a module load? Probably we should add one in /import-maps

Thanks for the info.
Added/Updated WPT for /trusted-types.
Where there's a will, there's a way.

When the preloaded request is reused during parsing, merge the preloaded
resolved module set into the global resolved module set to ensure consistency.

Originally, RegisterImportMap was not invoked if any module requests
were in the fetching or fetched state. With this limitation removed,
the behavior is updated so that only the preloading requests are canceled.

https://treeherder.mozilla.org/jobs?repo=try&revision=4453b9339b5c1268177500a3469cd242f21127e3

Add a pref to enable support for multiple import maps.

Calling DisallowImportMaps() conditionally if the pref is off.

Reset modules information happened during preload.

[Updated on 2026.Feb.23]
try: https://treeherder.mozilla.org/jobs?repo=try&revision=57a58217d982492b7b253212faad85922e9abc6a
(pref is on): https://treeherder.mozilla.org/jobs?repo=try&revision=2a7aa04de4707574ac721c94bfdd2d353e97530e

Currently Gecko only set mIsPreload to true for the top-level preloading
load. To identify a non-top-level preload, update mIsPreload accordingly
to match the mIsPreload flag from the root module.

This will allow us to identify the module is loaded during preloading
phase.

https://hg.mozilla.org/mozilla-central/rev/3a76af935b1d
https://hg.mozilla.org/mozilla-central/rev/56b312c1f37d
https://hg.mozilla.org/mozilla-central/rev/f9d983d1e3e2
https://hg.mozilla.org/mozilla-central/rev/fa2331e74853
https://hg.mozilla.org/mozilla-central/rev/15eeb297ee62
https://hg.mozilla.org/mozilla-central/rev/2c99c4ed2495
https://hg.mozilla.org/mozilla-central/rev/bc51a6464df2
https://hg.mozilla.org/mozilla-central/rev/bb6a7df845a8
https://hg.mozilla.org/mozilla-central/rev/0c2d420621fb
https://hg.mozilla.org/mozilla-central/rev/61bba4bc022d
https://hg.mozilla.org/mozilla-central/rev/89c6089e6a89
https://hg.mozilla.org/mozilla-central/rev/cb9f3ad567ab
https://hg.mozilla.org/mozilla-central/rev/a5d469a28b3a
https://hg.mozilla.org/mozilla-central/rev/3962bb975cde
https://hg.mozilla.org/mozilla-central/rev/f0f9edc6c0c2
https://hg.mozilla.org/mozilla-central/rev/c497a8561d89
https://hg.mozilla.org/mozilla-central/rev/38d64e1c3b2c
https://hg.mozilla.org/mozilla-central/rev/40e922e2c3b7

:allstars.chh is this something you want to mention in the Fx150 release notes? Feel free to nominate if so.

Release Note Request (optional, but appreciated)

[Why is this notable]:
The current restriction to a single import map imposes several limitations. Enabling support for multiple import maps would lift these constraints and provide increased flexibility for web developers.

[Suggested wording]:
Multiple Import Maps

Added to Fx150 release notes https://www.firefox.com/en-US/firefox/150.0a1/releasenotes/

(In reply to Dianna Smith [:diannaS] from comment #48)

Added to Fx150 release notes https://www.firefox.com/en-US/firefox/150.0a1/releasenotes/

Hi, Dianna,
I'd like to remind you that the feature is behind the pref "dom.multiple_import_maps.enabled", which is still off by default.

The note doesn't mention that and I think it will cause some confusion.

Firefox now supports multiple import maps per document ...

See the pref in
https://searchfox.org/firefox-main/rev/83d1a08db47b91a4d53341a799745caac9c38bde/modules/libpref/init/StaticPrefList.yaml#3769-3773

my apologies I didnt realize it was off by default. Is there a ticket tracking it being enabled? I can remove the relnote until that happens.

(In reply to Dianna Smith [:diannaS] from comment #50)

my apologies I didnt realize it was off by default. Is there a ticket tracking it being enabled? I can remove the relnote until that happens.

bug 2021012, although I don't know if we should put some experienment feature (off by default) in relnote.

I can add something like "Starting with Firefox 150, multiple import maps per document is now supported, giving web developers more flexibility when structuring and loading modern JavaScript modules. This is considered experimental as we gather feedback before enabling it in regular releases." Please let me know how that sounds.

(In reply to Dianna Smith [:diannaS] from comment #52)

I can add something like "Starting with Firefox 150, multiple import maps per document is now supported, giving web developers more flexibility when structuring and loading modern JavaScript modules. This is considered experimental as we gather feedback before enabling it in regular releases." Please let me know how that sounds.

That looks perfect, thanks.
(And I assume you will add it in https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/150#experimental_web_features, with mentioning the pref "dom.multiple_import_maps.enabled")

For the mdn changes, the dev-doc-needed keyword would move to
dev-doc-complete when someone from the mdn makes the change

FF150 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/43551