ESM Import Map

This page demonstrates the usage of import maps.

In Firefox, be sure to flip dom.importMaps.enabled on in the about:config configuration page.

Learn about import maps here.

This page references a ES module script which in turn references another module using the bare specifier module. By default in a browser, using a bare specifier results in an error. However, with import maps, bare specifiers can be mapped to other path.

Example


      import test from 'module';

This would have been an error normally… However, when we add an import map prior to where we reference the script with imports using bare specifiers:


      <script type="importmap">
        {
          "imports": {
            "module": "./module-a.js"
          }
        }      
      </script>

The code runs just fine… The import of module in the script will resolve to module-a.js. You can see this in action using this button. It shows a JavaScript alert with the value of the default export of that script.

What will happen if we change the content of the import map after the script using it to resolve its dependencies has loaded? Use this button to change the content of the import map to one such that module now maps to module-b.js.

Click the Test button again. It still shows the resolved content of the module-a.js script. So, it looks like dynamically refreshing the import map won't re-resolve modules as per the latest import map configuration.

But what happens when we do a dynamic import? Press the button below to load module using dynamic import and let's see if it produces a or b.

Hmm, even now, the module always resolves to module-a.js and that happens regardless of whether the Test button is pushed prior (hypothesis being that it somehow "solidifies" the resolved graph), it just shows a no matter what.

I do see the script[type="importmap"] updating its content in the DOM though. I wonder if manually inserting a new import map script might cause something to kick in that doesn't when updating the content of the existing script.

The button below removes the existing source map from the DOM and inserts a new one, pointing to the module B.

Alright, it seems as though it is just straight not possible to amend an existing import map once it is resolved for the initial time.

Next I wonder whether there can be two import maps which get merged when the resolution happens. I have added a new one (to the HTML) and this next Test button uses a bare specifier for another mapped word which comes from the second import map. Let's see if the browser is smart enough to figure this out.

Whoah! This doesn't work! I fully expected the browser would merge the import maps into one.

This means that the only possible avenue of having fun with import maps at runtime left is to see whether when a page is loaded with no import map, then one is added dynamically and then module scripts are encountered and those use bare specifiers, whether that will work; whether the dynamic import map will be respected.

I cannot test this in this same file because it already has static import maps for the previous tests, but I have made another file where to test this.

See here