Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infinite TypeScript Type Generation When Using Self-Reference in Module Federation (Rsbuild v2.0) #3490

Open
5 tasks done
Voloshch opened this issue Feb 6, 2025 · 4 comments
Assignees

Comments

@Voloshch
Copy link

Voloshch commented Feb 6, 2025

Describe the bug

I'm trying to create a single store instance in the host application (federation_consumer) and use it in both the host and remote applications. However, I am experiencing an issue with infinite TypeScript type generation when using rsbuild with Module Federation v2.0.

  • This issue does NOT occur in Rsbuild v1.5.
  • It also does NOT occur in production mode (after the build is complete).

The problem seems to be related to the self-reference of the host in rsbuild.config.ts.

Steps to Reproduce

  1. Configure rsbuild.config.ts in the host application:
import { defineConfig } from '@rsbuild/core';
import { pluginReact } from '@rsbuild/plugin-react';
import { pluginModuleFederation } from '@module-federation/rsbuild-plugin';

export default defineConfig({
  plugins: [
    pluginReact(),
    pluginModuleFederation({
      name: 'federation_consumer',
      remotes: {
        federation_provider: 'federation_provider@http://localhost:3000/mf-manifest.json',
        federation_consumer: 'federation_consumer@http://localhost:2000/mf-manifest.json', // Self-reference
      },
      getPublicPath: `function() { return "http://localhost:2000/" }`,
      exposes: {
        './store': './src/store.ts',
      },
      shared: ['react', 'react-dom'],
    }),
  ],
  server: {
    port: 2000,
    headers: {
      'Access-Control-Allow-Origin': '*',
    },
  },
});
  1. Use the shared store in App.tsx:
import ProviderButton from 'federation_provider/button';
import { useAppStore } from 'federation_consumer/store'; // Importing store from self-reference

const App = () => {
  const { count, reset } = useAppStore();

  console.log(count);

  const onReset = () => {
    reset();
  };

  return (
    <div className="content">
      <h1>Rsbuild with React</h1>
      <p>Start building amazing things with Rsbuild.</p>
      <button onClick={onReset}>Reset</button>
      <div>
        <ProviderButton />
      </div>
    </div>
  );
};

export default App;

Reproduction

https://github.com/Voloshch/rsbuildmfe

Used Package Manager

npm

System Info

OS: Ubuntu 22.04
Node: 20.9.0
npm: 10.1.0
react: 19.0.0
typescript: 5.7.3
@rsbuild/core: 1.2.3
@module-federation/rsbuild-plugin: 0.8.9

Validations

@ScriptedAlchemy
Copy link
Member

Why would you self reference, this will cause runtime errors in your application. The bundler runtime will collide with its remote counterpart as they both replace eachothers global callbacks

@artieeez
Copy link
Contributor

artieeez commented Feb 25, 2025

My colleagues and I also started our journey with module federation by using self-reference for a similar reason—to ensure that the states created in the root/shell MFE would remain singletons across the system. It even made it to production for a while, but we eventually had to find alternatives as other problems emerged from this arrangement.

To follow @ScriptedAlchemy advice and avoid self-reference, consider moving your stores outside the root MFE. You can either define them in a remote or create a shared package to house those global stores.

That said, while I don’t recommend this approach, disabling dts.generateTypes.extractRemoteTypes should prevent the recursive behavior in this particular case.

@ScriptedAlchemy

This seems like a common use case—defining a store in the root/ shell MFE and discovering that exposing it creates one instance for the app entry point and another for the expose in MF. Do you know of any better solutions than the ones I mentioned above?

@ScriptedAlchemy
Copy link
Member

Ill look into the self reference issue - tho generally dont recommend, id use shared to share it as a singleton etc, or use a runtime plugin.

@FaureWu
Copy link

FaureWu commented Mar 1, 2025

It is equally important to me. I need this capability to implement cross-end components.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants