Dynamic/runtime remotes

[foot]

Is your feature request related to a problem? Please describe.

We want to get a list of remotes at runtime from another api service. e.g. GET /api/services. From the examples here I can only see how to do this at build time by specifying the remotes in vite.config.js or rollup config.

Describe the solution you'd like

We would like to dynamically load remotes at runtime, here is an example of doing it w/ webpack and their "container" model:

https://github.com/module-federation/module-federation-examples/blob/master/dynamic-system-host/app1/src/App.js

I've had a bit of look into some of the code in expose-dev.ts but its still early for me.

Does this sound feasible?

Describe alternatives you've considered

Trying to use systemjs perhaps?

[ruleeeer]

I looked at dynamic-system-host/app1/src/App.js, it feels more similar to a component that can switch remote rather than directly giving an interface like GET /api/services, similar to what dynamic-system-host/app1/src/App.js does It can be done, because the implementation of vite-plugin-federation refers to webpack, maybe later we will provide an example, but this may take some time, if you want to build a similar project, I suggest you check out any project host-side dist/index.js in the example directory, they show the initialization process of a remote component, here I attach a part of the example/vue3-demo-esm/layout/dist/assets/index.js file

const remotesMap = {
  'home': {url: 'http://localhost:5001/assets/remoteEntry.js', format: 'esm'},
  'common-lib': {url: 'http://localhost:5002/assets/remoteEntry.js', format: 'esm'},
  'css-modules': {url: 'http://localhost:5003/assets/remoteEntry.js', format: 'esm'}
};
const loadJS = (url, fn) => {
  const script = document.createElement('script');
  script.type = 'text/javascript';
  script.onload = fn;
  script.src = url;
  document.getElementsByTagName('head')[0].appendChild(script);
};
const scriptTypes = ['var'];
const importTypes = ['esm', 'systemjs'];
const metaGet = name => __federation_import(name);
const webpackGet = name => metaGet(name).then(module => () => module?.default ?? module);
const shareScope = {
  'vue': {
    '3.2.23': {
      metaGet: () => metaGet('./__federation_shared_vue.js'),
      get: () => webpackGet('./__federation_shared_vue.js'),
      loaded: 1
    }
  },
  'vuex': {
    '4.0.2': {
      metaGet: () => metaGet('./__federation_shared_vuex.js'),
      get: () => webpackGet('./__federation_shared_vuex.js'),
      loaded: 1
    }
  }
};

async function __federation_import(name) {
  return __vitePreload(() => import(name), true ? [] : void 0);
}

var __federation__ = {
  ensure: async (remoteId) => {
    const remote = remotesMap[remoteId];
    if (!remote.inited) {
      if (scriptTypes.includes(remote.format)) {
        // loading js with script tag
        return new Promise(resolve => {
          const callback = () => {
            if (!remote.inited) {
              remote.lib = window[remoteId];
              remote.lib.init(shareScope);
              remote.inited = true;
            }
            resolve(remote.lib);
          };
          loadJS(remote.url, callback);
        });
      } else if (importTypes.includes(remote.format)) {
        // loading js with import(...)
        return new Promise(resolve => {
          __vitePreload(() => import(/* @vite-ignore */ remote.url), true ? [] : void 0).then(lib => {
            if (!remote.inited) {
              lib.init(shareScope);
              remote.lib = lib;
              remote.lib.init(shareScope);
              remote.inited = true;
            }
            resolve(remote.lib);
          });
        })
      }
    } else {
      return remote.lib;
    }
  }
};

This code shows how to initialize a remote component, note that the logic of loading a remote component generated by webpack is different from that of loading a remote component generated by vite-plugin-federation, because webpack uses iife by default and needs to be loaded using <script src=... > to load them, while for vite-plugin-federation they will be loaded directly using esm's import

[foot]

Brilliant! Thank you for the quick reply, I'll have a play around w/ the code.

it feels more similar to a component that can switch remote rather than directly giving an interface like GET /api/services

Yes indeed, the webpack example just switches things in and out. It looks it could be adapted into something more generic that could hopefully take a list of remotes from some other source and display them all in a navbar / menu for example.

[foot]

Code works great for prod!

const RemoteButton = React.lazy(
  // Normal way of loading things
  // @ts-ignore
  // import("remote_app/Button")

  // Use new loader
  () => {
    remotesMap["remote_app"] = {
      url: "http://localhost:5001/assets/remoteEntry.js",
      format: "esm",
    };

    return __federation__
      .ensure("remote_app")
      .then((remote) => remote.get("./Button").then((factory) => factory()));
  }
);

Dev looks a bit more hairy.. 🤔 .

Could we expose the remotesMap for modification by the app code at runtime do you think? I've noticed __federation_shared__ around which I guess needs to be global for the expose code to hook in. Something like globalThis.__federation_remotes_map__ = remotesMap ?

This is a bit hacky. I guess it would be neat to have some runtime lib import { addRemote } from "@originjs/vite-plugin-federation";

[foot]

Sorry, I guess the "problem" now is how to get shareScope at runtime: (the main thing being the paths to the js code (__federation_shared_vue.js)).

const shareScope = {
  'vue': {
    '3.2.23': {
      metaGet: () => metaGet('./__federation_shared_vue.js'),
      get: () => webpackGet('./__federation_shared_vue.js'),
      loaded: 1
    }
  },
  'vuex': {
    '4.0.2': {
      metaGet: () => metaGet('./__federation_shared_vuex.js'),
      get: () => webpackGet('./__federation_shared_vuex.js'),
      loaded: 1
    }
  }
};

Perhaps we could always set __federation_shared__ in the code generated by vite that could be read at runtime even before trying to import/ensure another remote? There are perhaps hacks here like trying to load a dummy remote first to make sure window/__federation_shared__ is available before loading dynamic remotes..

[ruleeeer]

I have something to say about dev mode, because vite does not support adding a bundle in dev mode (actually it is the remoteEntry.js file), so now the dev mode of vite-plugin-federation only supports the host side, the remote side cannot run in dev mode.

Code works great for prod!

const RemoteButton = React.lazy(
  // Normal way of loading things
  // @ts-ignore
  // import("remote_app/Button")

  // Use new loader
  () => {
    remotesMap["remote_app"] = {
      url: "http://localhost:5001/assets/remoteEntry.js",
      format: "esm",
    };

    return __federation__
      .ensure("remote_app")
      .then((remote) => remote.get("./Button").then((factory) => factory()));
  }
);

Dev looks a bit more hairy.. 🤔 .

Could we expose the remotesMap for modification by the app code at runtime do you think? I've noticed __federation_shared__ around which I guess needs to be global for the expose code to hook in. Something like globalThis.__federation_remotes_map__ = remotesMap ?

This is a bit hacky. I guess it would be neat to have some runtime lib import { addRemote } from "@originjs/vite-plugin-federation";

[ruleeeer]

It sounds crazy to load the shared before loading the module,Perhaps we need to seriously consider how to achieve this, because in theory we need to determine which shared libraries are used by the component and then load the corresponding shared, it's the Chinese New Year, my reply may be late, don't mind

Sorry, I guess the "problem" now is how to get shareScope at runtime: (the main thing being the paths to the js code (__federation_shared_vue.js)).

const shareScope = {
  'vue': {
    '3.2.23': {
      metaGet: () => metaGet('./__federation_shared_vue.js'),
      get: () => webpackGet('./__federation_shared_vue.js'),
      loaded: 1
    }
  },
  'vuex': {
    '4.0.2': {
      metaGet: () => metaGet('./__federation_shared_vuex.js'),
      get: () => webpackGet('./__federation_shared_vuex.js'),
      loaded: 1
    }
  }
};

Perhaps we could always set __federation_shared__ in the code generated by vite that could be read at runtime even before trying to import/ensure another remote? There are perhaps hacks here like trying to load a dummy remote first to make sure window/__federation_shared__ is available before loading dynamic remotes..

[T0miii]

__federation__ 

do you have an example project for this, im trying to implement the same thing in Vue that looks something like this:

const BataButton = defineAsyncComponent({
  loader: () => {
    remotesMap["bata-lib"] = {
      url: "http://localhost:4173/assets/remoteEntry.js",
      format: "esm",
    };

    return __federation__
        .ensure("bata-lib")
        .then((remote) => remote.get("./BataButton").then((factory) => factory()));
  },
  errorComponent: ErrorComponent,
});

I dont realy know how to get the missing variables remotesMap and federation

[ruleeeer]

@T0miii I think the current does not fully provide open remoteMap and __federation ability, perhaps discuss how to achieve this part of the function, this is not a complex function, just I think similar to globalThis.remoteMap such a way too bad taste,and may lead to unknown security problems

[ruleeeer]

I'll start experimenting with this part of the feature when I have more free time

[itschip]

Any news on this? Currently playing around with this.

[fgatti675]

Hi everyone!
Thanks a lot for this great library. Module federation is exactly what we need for developing a complex system in our current project.
We need our users to be able to upload their own modules which then get run in our main application, which gets bundled using vite.
In order to achieve this we need to be able to use dynamic remotes, but I am having a hard time following this code!
Would it be a lot to ask for a working example with dynamic remotes?
It would help us a ton.
Thank you!!

[T0miii]

@foot Hi, i dont know if you are still working with federation, but did you manage to make dynamic imports work?
const moduleName = 'app/Counter'
import(/* @vite-ignore */ moduleName)

when i try doing the following vite still errors out, saying it cant resolve app/Counter.

[foot]

Hiya, no, I haven't had the chance to dig more into module federation.

It looks like this PR landed #163

Which is probably a good starting point and may help with your use case?

[T0miii]

Yes i have seen this, guess this is solving the problem where the URLs are unknown at build time.
In my case or what im trying to figure out how would be possible to import modules where the module name is unknown at build time.

[foot]

Yeah. It sounds like there is a bit of interest in the feature. I've lost all my old code.

If you have time to put up a PR that copies one of the existing examples and adapts it to try and do a dynamic import, that would be a great place to iterate.

[foot]

Here is an updated POC example of a dynamic remote, seems to work?

https://github.com/foot/vite-plugin-federation/pull/1/files

It needs some code changes to the plugin to modify the remotesMap.

@ruleeeer wdyt about something like this?

[T0miii]

@ruleeeer would this be a possibility?

[BEGEMOT9I]

+1, think it will be a killer feature :D

[js-lowes]

bump this, definitely would want this feature. What blockers are in front of us, seeing how I can possibly contribute?

[foot]

What blockers are in front of us, seeing how I can possibly contribute?

🎉

• @ruleeeer has mentioned security concerns further up which I think is a very good point. Webpack has their container model for dynamic loading, understanding what security precautions (if any) they have taken and discussing them here to include in a possible implementation would be neat.
• The POC https://github.com/foot/vite-plugin-federation/pull/1/files is very much a POC, there are some obvious FIXMEs but probably other issues too, FIXMEs:
  • Avoid creating double imports of __federation__
  • Avoid requiring a dummy remote -- e.g. load in the shared modules automatically in some cases.
  • ?

[js-lowes]

I started looking into these and realize how little understanding of what is going on I have :/ Wish I could allocate some more time to really do a deep dive to wrap my head around "the magic". Not sure when Ill have time todo that.

[Nandez89]

I arrived a bit later to this, but really interested in this feature, it will sadly be a blocker for us and become a turning point to switch out of vite if we can't do this dynamic module federation imports for our new product.

Any status updates from people on the thread?

[LechLee]

Manage to solve the issue, it is caused by empty remotes in my federation setup, and it needs a dummy to fix '__rf_placeholder__shareScope is not defined' as refer from above example

App.jsx

import { __federation_method_setRemote, __federation_method_getRemote } from '__federation__'

const RemoteApp = lazy(() => {
	__federation_method_setRemote('remote-app', {
		url: () => Promise.resolve('http://localhost:8080/assets/remote-entry.js'),
		format: 'esm',
		from: 'vite'
	})

	return __federation_method_getRemote('remote-app', './App')
})

const App = () => {
      return <RemoteApp />
}

vite.config.js (host)

federation({
            name: 'host-app',
            remotes: {
                // "ReferenceError: __rf_placeholder__shareScope is not defined"
                dummy: "dummy.js",
            }
        })

vite.config.js (remote)

federation({
            name: 'remote-app',
           exposes: {
		'./App': './src/App'
	}
        })

[kpfrang]

We encountered the same problem when omitting remotes or leaving it empty. Adding a dummy solved it for us.

plugins: [
    federation({
        remotes: { dummyRemote: 'dummyRemote.js' },
    })
]

[MartinWeb]

I manage to make it work as well and it's amazing, but can anyone explain me how this import is working
import { __federation_method_setRemote, __federation_method_getRemote } from '__federation__'
I cannot find any definition for __federation__ in the exports of the package and so i am a bit confused of how it is working.
It is working, which is great, but still seems like magic.

[AntonyF-Andreani]

@MartinWeb it's a virtual module, generate te definition with the x plugin.

https://vitejs.dev/guide/api-plugin#virtual-modules-convention

[MartinWeb]

Thanks @AntonyF-Andreani i understand better now.

[husayt]

The issue is solved with latest release. Thanks to everyone involved.

[hdwong]

I get this error in my DevTools:

My environment is using vite+react, and the key code is as follows:

const Component = lazy(() => {
  __federation_method_setRemote('remote-app', {
    url: 'http://127.0.0.1:3000/assets/remoteEntry.js',
    format: 'esm',
  });
  return __federation_method_getRemote('remote-app', remotePath)
      .catch(() => ({ default: () => <div>Page Not Found</div> }));
});

[AntonyF-Andreani]

Hi @hdwong where did you get the example? I have tried to search for it without any succes.

[HyperClockUp]

it does work, thank you!

i found the solution:

    const module = await __federation_method_getRemote(
      remoteName,
      `./${componentName}`
    );
    return {
      default: module,
    };

the point is that you shoud return object contains default

[Imad8101]

@HyperClockUp can you pls provide detailed solution ?

[Imad8101]

I'm getting this with React vite and getting this error
Uncaught SyntaxError: Identifier '__federation_method_getRemote' has already been declared

import { __federation_method_setRemote, __federation_method_getRemote } from '__federation__';

const loadComponent = async (remoteName, componentName) => {
  const module = await __federation_method_getRemote(remoteName, `./${componentName}`);
  return {
    default: module
  };
};

const RemoteApp = React.lazy(() => {
  __federation_method_setRemote('dashboard', {
    url: () => Promise.resolve('http://localhost:3001/assets/remoteEntry.js'),
    format: 'esm',
    from: 'vite'
  });

  // return __federation_method_getRemote('dashboard', './App');
  const prom = loadComponent('dashboard', 'App');
  return prom;
});

[husayt]

Try

import {
  __federation_method_setRemote,
  __federation_method_getRemote
} from "virtual:__federation__";

[itschip]

This might be and hopefully someone has some insight, but here's my issue as of now as soon as using hooks.

Uncaught Error: Minified React error #321; visit https://reactjs.org/docs/error-decoder.html?invariant=321 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at p (__federation_shared_react-e4fb71e0.js:12:3773)
    at o.useState (__federation_shared_react-e4fb71e0.js:12:5894)
    at j (App-d9b67ed6.js:1:933)
    at renderWithHooks (react-dom.development.js:14985:18)
    at mountIndeterminateComponent (react-dom.development.js:17811:13)
    at beginWork (react-dom.development.js:19049:16)
    at HTMLUnknownElement.callCallback2 (react-dom.development.js:3945:14)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:3994:16)
    at invokeGuardedCallback (react-dom.development.js:4056:31)
    at beginWork$1 (react-dom.development.js:23964:7)  

Both the host and remote uses the the same react and react-dom version, although I likely think the shared thingy is the issue.
I'm very lost as of right now, so if anyone has some pointers, that'd be nice.

This is how I'm loading the app (works just fine without hooks)

__federation_method_setRemote(scope, {
        url: () => Promise.resolve(url),
        format: 'esm',
        from: 'vite',
      });

      const mWrapper = await __federation_method_getRemote(scope, './config');
      const m = await __federation_method_unwrapDefault(mWrapper);

      const appConfig = m();

      console.log('Loaded external app config', appConfig);

      const config = appConfig;
      config.Component = (props: object) => React.createElement(config.app, props);

      const Provider = createExternalAppProvider(config);

      config.Route = (props: any) => {
        return (
          <Route path={config.path}>
            <Provider>
              <config.Component />
            </Provider>
          </Route>
        );

I've got the remote vite config:

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: 'mockapp',
      filename: 'remoteEntry.js',
      exposes: {
        './config': './npwd.config.ts',
      },
      shared: ["react", 'react-dom']
    }),
    topLevelAwait({
      // The export name of top-level await promise for each chunk module
      promiseExportName: "__tla",
      // The function to generate import names of top-level await promise in each chunk module
      promiseImportName: i => `__tla_${i}`
    })
  ],
  server: {
    port: 3002,
  },
  build: {
    modulePreload: false,
  }
});

Here's the npwd.config.ts file:

import App from './src/App';
import { AppIcon } from './icon';

interface Settings {
  language: 'en';
}

export const path = '/mockapp';
export default (settings: Settings) => ({
  id: 'MOCKAPP',
  path,
  nameLocale: "Mockapp", 
  color: '#fff',
  backgroundColor: '#333',
  icon: AppIcon,
  app: App,
});

and then a very simple App component:

import React, { useState } from 'react';
import { i18n } from 'i18next';

interface AppProps {
  theme: any;
  i18n: i18n;
  settings: any;
}

export function Counter() {
  const [counter, setCounter] = useState(0);
  return (
    <div style={{ color: "white" }}>
      <h1>HELLLO WORLD</h1>

      <p>Counter: {counter}</p>
      <button onClick={() => setCounter((prev) => prev + 1)}>Increment</button>
    </div>
  );
}

export function App() {
  return (
    <div style={{ color: "white" }}>
      <h1>HELLLO WORLD</h1>

      <Counter />
    </div>
  );
};

export default function WithProviders() {
  return (
    <App />
  )
}

[itschip]

Nevermind, I am dumb af.

I forgot to set shared in the host vite config 🤣

[mxvsh]

any update on this?

[itschip]

@mxvsh anything specific you're looking for?

[tvladimir]

I'm looking for a working example of dynamically loading remotes from the window.remoteConfig.remotes array for React.
So, it might be a header, sidebar, or footer; they will come from remotes, but routing remotes, I want get dynamic

[tvladimir]

Here is a working example
https://medium.com/@lester.sconyers/dynamic-module-federation-with-vite-0bce2bfcc517
But there are still some problems with CSS loading

[husayt]

I wonder if you had any luck with those nasty Css issues?

[LechLee]

Anyone get it to work with Host in dev mode, and Remotes in production mode?

Based in the READMD.md it should work, but read me only have the example static hosting

I'm getting this error when Host in dev mode, and Remotes in production mode, when loading the Remotes
Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object

[husayt]

you need this to be merged for that to work. Try poking maintainers to approve the PR.

[LechLee]

Did you mean the static remotes will not work without this PR? or only dynamic remotes?

[crimson-med]

So I've managed to make the dynamic import work:

  const RemoteApp = lazy(() => {
    __federation_method_setRemote(`remote-${id}`, {
      url: () => Promise.resolve(remote),

      format: 'esm',
      from: 'vite',
    });

    return __federation_method_getRemote(`remote-${id}`, component);
  });

The main issue is when writting tests for the components then the federation module is not available.

Has anyone manage to write tests and simulate the module: federation

custom/__tests__/MicroFrontend.test.tsx [custom/__tests__/MicroFrontend.test.tsx ]


Error: Failed to resolve import "__federation__" from "custom/MicroFrontend.tsx". Does the file exist?

[im-sivaprakash]

Just started working on Vite with micro front, from all the above discussions I could able to load the remote component only in prod not in dev mode. And when I stop the remote the host/shell goes blank. This would be easily achievable with Webpack . Just let me is this a vite's limitation.

[jarecsni]

Does anyone know if it's possible to use shared libraries with dynamic federation? I suppose the host config should include a shared: ['react'] in its federation config (with the dummy module), and the remote module also has to list shared libraries like react. Does it sound correct?