Portability concerns of non-string specifiers & import maps integration

[guybedford]

In the recent incubator call the proposal at #5 was discussed, which proposes replacing string fragments with module identifiers that can be imported and exported.

I wanted to just follow up with one explicit workflow concern around these identifier versus string module fragments.

Consider a framework peer dependency like react or lit that is a base dependency in a component model. We bundle the primary application using module fragments.

Now at runtime if we want to load components that were not included in the original bundle, we cannot import components that are written using the common pattern:

import * as React from 'react';

As we would now need to effectively change this to use the identifier fragment double import pattern:

import { reactModule } from '/core-bundle.js';
import * as React from reactModule;

The concern here is that it creates a requirement on all subsequent code loaded that it is syntactically changed based on knowing the internal bundling pattern and assumptions.

With the current module fragments proposal one could just define an import map:

<script type="importmap">
{
  "imports": {
    "react": "/bundle.js#react"
  }
}
</script>

which would allow the third-party code to correctly reference the bundled framework.

Because such techniques are no longer possible, this instead places a very specific semantic burden on any subsequently loaded code that inhibits code portability between bundles.

I think we need to think carefully about this problem and ensure there are solutions available if wanting to move forward with such a scheme.

[devsnek]

this could be a great place to make use of nested import bindings in the lhs, like many other languages with nested modules allow.

[littledan]

Thanks for posting this issue @guybedford . I'm convinced that there's no need to merge module blocks and module fragments (blocks can just come first, and fragments build on top), and that this is an important issue to solve if import maps are destined to be part of the standard, multiple-implementation web platform.

There are simple solutions on the import maps side, if we want them to be able to address modules that are exported from other modules. To take the example you gave, if we have bundle like

export module react { export React = {/* */}; }

then we might be able to point to it with an import map with syntax like this:

<script type="importmap">
{
  "imports": {
    "react": { "import": "react", "from": "/bundle.js" }
  }
}
</script>

The only technical barrier that I see is that this syntax is one-off for import maps, and we might find ourselves developing another syntax for some other context where JSON is not suitable. (Multiple levels of nesting are not supported here--they could be, but also I don't understand what the motivation would be.)

[nicolo-ribaudo]

Could the import map point to an intermediate module that does this?

import { reactModule } from '/core-bundle.js';
export * from reactModule;
export { default } from reactModule;