UIXP for Javascript modules importmap

Development
1

Hello all,

This post is a proposal for the addoption of es6 module’s importmap.

After working with various approaches to module import and declaration (e.g., requirejs that we are currently using), Javascript (es6) now offers modules that are supported by all the browsers we support.
This comes with the advantage of being widely supported, avoiding the need for the now date requirejs library.

Very roughly, the syntax is:

import './file.js' // import relatively to the current file
import "another-module" // resolve to a another module by it's id

When import "another-module" the browser resolves the identifier and provides it to the importing module.
This is where using importmap is useful. An importmap provides a mapping between module ids and their URLs.

For instance, to indicate where another-module is located:

<script type="importmap">
  {
    "imports": {
      "another-module": "http://localhost:8080/myfile.js"
    }
  }
</script>

Note that I introduced importmap in the form as an UIXP in javascript.vm in my Vue 3 migration pull request.

So two questions:

  1. do you agree with the conceptual idea to introduce a support for importmap in our code base?
  2. let me know what you think of my current implementation (that I’ll probably move to a separate PR once the general idea is agreed on)

Thanks!

2

+1 for introducing support for importmap.

Now what I don’t understand is why every UIX needs to provide the JSON itself and what advantage that provides over just using a UIX with org.xwiki.platform.html.head as extension point that also includes the wrapping <script> tag.

We could instead have the module name and the URL as parameters in the UIX and let the UIXP generate the JSON out of that. This means you would need one UIX per module, though, I don’t know if that would be a serious limitation or not.

3

The main advantage is to have specialized UIX(P)s. I feel like they are easier to discover (i.e., not having to search inside all org.xwiki.platform.html.head UIXs to find hypothetical importmap specific ones).
Moreover, this avoids duplicating the wrapping <script type='importmap'> element every time.
Nothing technically mandatory, but I think it makes for a better developer experience.

It would work for simple cases like the one I presented in my initial post.
But, importmap are actually more advanced than that. Constraining to only a map of ids and urls would be constraining. Though, enough for our current needs.

Note that when several import maps are declared. They are merged together as a single json. When keys overlaps, the value of the one declared first is kept. So having several importmap script elements is fine.

4

Just a small general note that the more UIXPs we have, the harder it is to write a good-citizen skin (since the skin needs to support the UIXPs). So we probably need to be careful to not add too many UIXPs.

5

That’s a good point!

To keep the discussion up to date. After further discussion with @MichaelHamann I ended up using an org.xwiki.platform.html.head UIX injecting a script element.

1 Like