What is the expected implementation of dynamically registered remotes?

[oscar8880]

My use case is for dynamically loaded remotes based on a manifest. At runtime the host app fetches information about where to load remotes from and uses @module-federation/enhanced/runtime's registerRemotes to register them.

In a nutshell how I'm achieving this is like this: oscar8880/nx-module-federation-issues@789c10b

This works well with the exception of one issue reported here: #30274, and also the warning in console: [ Federation Runtime ]: The remote "shop" is already registered. Please note that overriding it may cause unexpected errors.

These above problems however are making me think that I'm not following best practice here, but I'm not sure what the alternative is. Is there some more established pattern for this dynamic use case?

My first instinct was to change the apps/host/rspack.config.prod.ts so that it had an empty array of remotes [], that way there's no need to force: true when registering the remotes later. However, the impact this has on the build is that is causes host to build its remotes as shared dependencies and when they are loaded they are sourced from host's assets, rather than wherever the remotes are actually deployed. That's obviously not desired behaviour for a micro frontend setup where apps are supposed to be deployed and consumed independently.

Hence, what I went for was to keep the remotes defined in the production config so they don't get bundled as shared deps, but this does then mean I need to force: true to override the remote definitions later.

Any thoughts on this topic would be appreciated! 😄