[RFC] Provide first-class support for Module Federation

[chenjiahan]

This RFC is intended to provide first-class support for Module Federation in Rsbuild.

Configuring MF

Rsbuild will provide a top-level moduleFederation option, which will make configuring MF in Rsbuild much easier.

• Type:

import type { ModuleFederationPluginOptions } from '@rspack/core';

type RsbuildConfig = {
  moduleFederation?: {
    options: ModuleFederationPluginOptions;
  }
  // ...other options
}

• Example:

// rsbuild.config.ts
export default defineConfig({
  moduleFederation: {
    options: {
      // ModuleFederationPluginOptions
    }
  }
});

The above example is equivalent to the following config:

// rsbuild.config.ts
export default defineConfig({
  dev: {
    assetPrefix: 'auto',
  },
  output: {
    assetPrefix: 'auto',
  },
  performance: {
    chunkSplit: {
      override: {
        chunks: 'async',
      },
    },
  },
  tools: {
    rspack(config, { rspack, target, appendPlugins }) {
      if (target === 'web') {
        appendPlugins(
          new rspack.container.ModuleFederationPlugin({
            // ModuleFederationPluginOptions
          }),
        );
      }
    },
  },
});

Details:

• chunks: 'async': the default chunks in Rsbuild is 'all', but split patch not working for MF, so we will need it to async to avoid the issue.
• assetPrefix: 'auto': the default assetPrefix (publicPath) in Rsbuild is '/', we need to set the default to auto to make MF work.
• Maybe we can adjust more default configurations for MF, this needs more feedback

MF Version

Rsbuild uses MF v1.5 by default. If there is a need for other versions in the future, we can provide the moduleFederation.version option.

// rsbuild.config.ts
export default defineConfig({
  moduleFederation: {
    // can be `1.0`, `1.5` or more
    version: '1.0',
    options: {
      // ModuleFederationPluginOptions
    }
  }
});

Server-side Federation

The moduleFederation option currently only takes effect for client bundles (target === 'web').

When Server-side federation is ready to use, we may also provide some form of support in Rsbuild.

For Modern.js

Modern.js is based on Rsbuild, so Modern.js projects can also use the new moduleFederation option.

And Modern.js will enable source.enableAsyncEntry by default when using the moduleFederation option, this allows Modern.js to automatically create asynchronous boundaries for entry points.

Related Issues

• [MF]: plugin for module federation

[9aoy]

why not a moduleFederation rsbuild plugin?

[chenjiahan]

Module Federation is a builtin plugin both in Webpack and Rspack, splitting a separate MF plugin in Rsbuild will not bring any benefits.

[douglaszaltron]

Congratulations on the work! 🎉

It would also be interesting to explore something with single-spa since many projects also work with it in webpack for microfrontend creation. Perhaps just applying examples of usage with module-federation and another with single-spa, thus covering the main microfrontend libraries.

[chenjiahan]

Thank you for your suggestion ❤️, we will consider providing an Rsbuild + Single SPA example, perhaps putting it in the https://github.com/rspack-contrib/rspack-examples repository.

[douglaszaltron]

Certainly!

Or even to facilitate a plugin for single-spa, as it's not something native in rspack and not included in the core like module-federation. But I'm not sure what would be the best approach. or if something is so simple that it doesn't justify a plugin? 🤔

[chenjiahan]

There can be an rsbuild-plugin-single-spa, similar to https://github.com/WJSoftware/vite-plugin-single-spa

Hope that one day the community can implement and maintain such a plugin 😄

[douglaszaltron]

Certainly! My main concern is exactly that: adding the plugin and ensuring that the community will contribute to keep it active. I don't have a clear view of the current usage state of single-spa.

[chenjiahan]

Haha, I have the same opinion too.

[chenjiahan]

@ScriptedAlchemy How do you feel about the naming of config, do you prefer moduleFederation or a shorter federation or mf?

[douglaszaltron]

The plugin and some examples in the context of Vite often use the term 'federation'

However, both 'federation' and 'mf' seem to be plausible choices.
The abbreviation 'mf' may suggest the idea of name abbreviation micro frontends (MF) that's not cool.

Currently, I am more inclined to follow the approach using the term 'federation.'

Plugin from vite

[chenjiahan]

Yes, federation seems like a good abbreviation, or just use the full spelling of moduleFederation.

[2heal1]

Because mf is a builtin plugin, so we can change the splitChunk value as function ,like this:

 function patchChunkSplit(compiler: Compiler, name: string): void {
    const { splitChunks } = compiler.options.optimization;
    const patchChunkSplit = (cacheGroup: CacheGroup) => {
      switch (typeof cacheGroup) {
        case 'boolean':
        case 'string':
        case 'function':
          break;
        //  cacheGroup.chunks will inherit splitChunks.chunks, so you only need to modify the chunks that are set separately.
        case 'object': {
          if (cacheGroup instanceof RegExp) {
            break;
          }
          if (!cacheGroup.chunks) {
            break;
          }

          if (typeof cacheGroup.chunks === 'function') {
            const prevChunks = cacheGroup.chunks;
            cacheGroup.chunks = chunk => {
              if (chunk.name && chunk.name === name) {
                return false;
              }
              return prevChunks(chunk);
            };
            break;
          }

          if (cacheGroup.chunks === 'all') {
            cacheGroup.chunks = chunk => {
              if (chunk.name && chunk.name === name) {
                return false;
              }
              return true;
            };
            break;
          }
          if (cacheGroup.chunks === 'initial') {
            cacheGroup.chunks = chunk => {
              if (chunk.name && chunk.name === name) {
                return false;
              }
              return chunk.isOnlyInitial();
            };
            break;
          }
        }
        default:
          break;
      }
    };

    if (!splitChunks) {
      return;
    }
    // patch splitChunk.chunks
    patchChunkSplit(splitChunks);

    if (!splitChunks.cacheGroups) {
      return;
    }

    // patch splitChunk.cacheGroups[key].chunks
    Object.keys(splitChunks.cacheGroups).forEach(cacheGroupKey => {
      patchChunkSplit(splitChunks.cacheGroups[cacheGroupKey]);
    });
  }

According above code , it will force remoteEntry not be affected by user's chunkSplit strategy , and the strategy will work as expected in other files .

[chenjiahan]

That's cool, I will try to integrate this solution. 👍