[TBD] feat(nf): Use es-module-shims during initFederation and loadRemoteModule to ensure having latest importMap

[jogelin]

Related to #489

Do not process host during initFederation

• The Host importmap.json is directly included in index.html. No need to process it anymore.
• The Host shared libraries are accessible before the Host is bootstrapped.
• Host externals are directly read from es-module-shims when processing the remotes

Remote unnecessary global cache for loading the remotes

• The processRemoteInfo and the loadRemoteModule are using directly es-module-shims
• No DOM modifications.
• The es-module-shims is directly used to load modules instead of caching not-updated

Process the remotes in parallel

• Runtime initialization with a lot of remotes can be slow. Use Promises.all for processing them in parallel.

With that approach, I can now use the import map override principle natively. All of the modifications were not required but I thought it was interesting to improve the bootstrap at runtime.

I am of course open to the discussion ;)

[manfredsteyer]

Thanks for this. I'm afraid this won't work. Perhaps we have different ideas in mind.

One aspect of federation is that it negotiates the versions to use. It might decide to go with a higher minor version provided by a remote. Hence, we cannot directly include the host's import map.

Also, we cannot rely on import map overrides, as this is only supported via shims, while the idea of module federation is to eventually provide the option to work without shims.

[jogelin]

One aspect of federation is that it negotiates the versions to use. It might decide to go with a higher minor version provided by a remote. Hence, we cannot directly include the host's import map.

I think I missed something sorry. Could you indicate where in the code the negotiation of versions is done? Is it related to the externals cache? Because I kept the principle of using the version of the host or another remote when processing the remote (see the tests).

Also, we cannot rely on import map overrides, as this is only supported via shims, while the idea of module federation is to eventually provide the option to work without shims.

Ok, I understand. I don't know if you saw my tweet about the single-spa agenda? It seems it is in discussion for single-spa to use es-module-shims instead of SystemJS. Something really interesting in the post is the part:

We also discussed possible collaboration with Zack Jackson on module federation's new runtime (called MFP) and whether that could help. Also discuss whether a service worker would be necessary or helpful to hook into the browser's loading of modules.

It is an interesting idea to hook files using a service worker and it seems this is what they discussed with Zack Jackson. I don't want to push for the overrides, the goal is not to use the overrides but to provide a way to change dynamically the URL of a module. If we use a service worker, for example on the manifest, it will not be linked to es-module-shims anymore.

In the current code, one thing to notice is that injecting the exposes in the importmap does not change anything because the exposes are always read from the cache.

That PR can be split in two. If the injection of the host doesn't fit, the most important part is to keep the list of remotes up to date with the es-module-shims which is still used for now in the loadRemoteModule right? My question is why do we create a cache that is not up to date when we can directly use es-module-shims as a cache? Why do we use the importShim with an URL instead of using the key of the exposes?