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! 😄

[oscar8880]

Following up with a workaround that I'm still not fully convinced is an intended, native-feeling, way of doing this, but sharing in case it is useful.

Essentially I now us the init runtime method to register the remotes from my overarching manifest, then prevent my host from re-registering the same remotes later via a runtime plugin.

Host uses runtime init before bootstrapping the application

import { init } from '@module-federation/enhanced/runtime';

// retrieve manifest with details of the MFEs
// format data to be suitable for init function
init({ name: "host", remotes });

import('./bootstrap').catch((err) => console.error(err));

Runtime plugin to prevent host attempting to re-register the same remotes:

import type { FederationRuntimePlugin } from '@module-federation/enhanced/runtime';

const remoteOverrideRuntimePlugin: () => FederationRuntimePlugin = function () {
  return {
    name: 'remote-override-runtime-plugin',
    beforeInit: ({ options, ...args }) => {
      return {
        options: {
          ...options,
          remotes: []
        },
        ...args,
      };
    }
  }
};
export default remoteOverrideRuntimePlugin;

Used in the host's prod build config

...
const config: ModuleFederationConfig = {
  ...baseConfig,
};

export default composePlugins(
  withNx(),
  withReact(),
  withModuleFederation(config, {
    dts: false,
    runtimePlugins: [
      path.resolve(__dirname, '.../remote-override-runtime-plugin.ts')
    ],
  })
);