🎉 Module Federation 2.0 released！

[zhoushaw]

Today, we are excited to announce the official release of Module Federation 2.0!
This new version is a collaborative effort between the ByteDance Web Infra team, the author of Module Federation, Zack Jackson
and several of our community members. Special thanks to @ilteoood, @patricklafrance and @crutch12.
Module Federation 2.0 addresses many issues from the previous version, building upon ByteDance's internal practices and the existing community ecosystem of Module Federation.

Why Use Module Federation 2.0?

Introduced by Webpack 5, Module Federation has been a significant feature for over three years.
As a module sharing solution, it has gained widespread adoption, especially in large web projects, enhancing the efficiency and simplicity of developing large applications and facilitating team collaboration.
However, with its broader use, new challenges have emerged.

Version 2.0 addresses these challenges with several enhancements:

• Best Practices: A new independent documentation site here includes best practices and configurations that enhance its usage.
• Decoupling Runtime from Build Tools: This version decouples the Runtime from build tools, standardizing implementation across various platforms and increasing the flexibility of module loading.
• Type Safety: The updated build plugin now automatically generates and loads types for TypeScript projects, with development mode synchronizing types to ensure safety.
• Debugging Tools: Enhanced debugging is facilitated by a new Chome DevTools, making the process more convenient and efficient.
• Deployment Platforms: The addition of the mf-manifest.json file protocol simplifies integration with deployment platforms, allowing for better management of version resources and versions.

Introduction to Features of Module Federation 2.0

New Documentation Site

The new documentation provides a detailed introduction to the applicable scenarios and capabilities of the framework. It covers the entire process from starting a project with Rspack to utilizing its features. Additionally, it offers an in-depth discussion and explanation of the configuration of its plugin.

Enhanced Module Loading Flexibility

The updated version brings significant changes. The runtime capabilities that were originally embedded in Webpack have been extracted to form a standalone SDK. This change allows for dynamic registration and loading of remote and shared modules without relying on any build tools. Moreover, the use of module preloading and runtime plugins has been enhanced, providing more powerful control over the module loading process.

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

init({
  name: '@demo/app-main',
  remotes: [
    {
      name: "@demo/app1",
      entry: "http://localhost:3005/mf-manifest.json",
      alias: "app1"
    },
    {
      name: "@demo/app2",
      entry: "http://localhost:3006/remoteEntry.js",
      alias: "app2"
    },
  ],
});

loadRemote("app2/util").then((md)=>{
  md.add(1,2,3);
});

Unified Build Tool Runtime

The new version of Rspack and the Webpack plugin adopts a completely new Runtime architecture. This means that build tools no longer need to be tightly bound to the logic of the Runtime. Thanks to the new Runtime's plugin mechanism and preloading capabilities, developers can enjoy more flexible and efficient control over module loading. Additionally, other build tools can also implement this standard, which not only reduces maintenance costs but also helps to maintain consistency and standardization of the runtime environment.

Type Hints

The new version introduces a groundbreaking feature - dynamic module type hints! This feature effectively solves the problem of type loss when converting local modules to dynamic remote modules in TypeScript projects. Now, using this plugin, you can not only automatically generate and use remote types but also achieve a real-time type update experience similar to npm link when all projects are running locally.

Chrome DevTools

The Devtool is a debugging tool developed specifically for this framework. It can clearly display the dependencies between modules, as well as the configuration of Expose and shared. Additionally, the tool supports proxying modules from online pages to the local development environment and maintains hot update functionality to provide a smooth development experience.

Manifest Protocol

The build plugin for Module Federation generates a Manifest file.
This file contains basic information about the system, such as remoteEntry, shared, exposes, remotes, chunks, and type.
This information is a cornerstone for analyzing dependencies between projects and helps us build and optimize the platform.
In this way, we can perform fine-grained version and gray release management of modules on different deployment platforms.
In addition, the build plugin and runtime can directly use the Manifest file protocol to implement more advanced features.
For example, the dynamic type hinting feature was developed in the latest version based on the Manifest file protocol.

Acknowledgments

The development of the new version of Module Federation could not have been possible without the inspiration and support from many projects within the community.
Here, we express our deep respect and gratitude to these projects:

• Webpack Module Federation. The new version of Module Federation was forked from it, redesigned and implemented on this basis.
• The Module Federation Universe repository. where the original implementation of Universe is the foundation of the new Module Federation.
• The Rspack project. The Rspack team implemented Module Federation based on Module Federation Runtime, ensuring full compatibility of 2.0 with the Rspack ecosystem.

Future Plans

Enhancing Developer Experience

Although the new version introduces dynamic type hints and Chrome Developer Tools support, the current functionality of the Chrome Developer Tools is still insufficient.
We plan to enhance the debugging tools for Module Federation, such as adding visualization features for shared reuse.

Providing High-Performance Solutions

As a solution for micro-frontend architecture, Module Federation also faces the unique "request waterfall problem" inherent to micro-frontend architectures.
To address this issue, Module Federation plans to provide a series of high-performance strategies, including Server-Side Rendering (SSR) and Data Prefetch.

Collaborating with Community Partners

The new features of Module Federation 2.0 are currently only supported by Webpack and Rspack, two build tools. Module Federation provides a rich set of basic SDKs, facilitating other build tools to extend and encapsulate on this basis. Currently, Module Federation is mainly used as a module sharing solution. Our plan is to combine it with upper-layer frameworks to provide a series of micro-frontend architecture best practices based on Module Federation. This will help developers better meet the needs of large web applications in micro-frontend architecture development.

[jame-earnin]

Providing High-Performance Solutions
As a solution for micro-frontend architecture, Module Federation also faces the unique "request waterfall problem" inherent to micro-frontend architectures.
To address this issue, Module Federation plans to provide a series of high-performance strategies, including Server-Side Rendering (SSR) and Data Prefetch.

This is one of the most important issues that need to be fixed in the Module Federation world.
However, thanks to ByteDance Web Infra, all contributors, and Zack for your hard working and contribution.

[zhoushaw]

Thank you for your reply, We are planning to solve the waterfall request problem, which will include two parts more multi-framework SSR capability support, interface request preloading. Related features will soon progress!

[duannx]

Hi, what exactly is Module Federation 2.0? Should we use @module-federation/enhanced for everything from now on? And why is this package still in version 0.1.11?

What is the status of @module-federation/next-mf in relation to Module Federation 2.0?

[zhoushaw]

Let me explain:

• Module Federation 2.0 does not refer to version 2.0. @module-federation/next-mf is now based on @module-federation/enhanced. @module-federation/enhanced can be understood as a version of module federation that is independent of the built-in version in webpack and includes many additional features.
• If you only need to use it in webpack and rspack versions, using @module-federation/enhanced can better meet the functionality of TypeScript type synchronization. @module-federation/enhanced will generate an additional mf-manifest.json file, and you only need to specify the remote to use this file to load remote modules and remote types.

[zhoushaw]

The current relationship is really not very clear and needs a document to describe it, I expect to add it in the near future :)

[duannx]

Thanks @zhoushaw for the clarification.

I still have a small concern. In the document of Federation Runtime, all the imports use @module-federation/enhanced/runtime except this one. I'm not sure if it is intended or not

[zhoushaw]

@module-federation/enhanced/runtime This is the intended use, so that when combined with the build tool, you can ensure that the same runtime instance is used.

[maksnester]

@module-federation/enhanced versioned as 0.x doesn't really communicate "go ahead and try it in production today" so I'm also a bit confused about the 2.0 release

[ATakaSKY]

Let me explain:

• Module Federation 2.0 does not refer to version 2.0. @module-federation/next-mf is now based on @module-federation/enhanced. @module-federation/enhanced can be understood as a version of module federation that is independent of the built-in version in webpack and includes many additional features.
• If you only need to use it in webpack and rspack versions, using @module-federation/enhanced can better meet the functionality of TypeScript type synchronization. @module-federation/enhanced will generate an additional mf-manifest.json file, and you only need to specify the remote to use this file to load remote modules and remote types.

Regarding point 2 here, I removed @module-federation/typescript package and could see types getting generated just with the @module-federation/enhanced package. However I don't see mf-manifest.json in the build folder. Is it specific to the setup where we have rspack configuration because I am working with a webpack config setup at the moment?

[ATakaSKY]

I found the issue here, I didn't have publicPath set due to which mf-manifest.json was not generating. Adding publicPath fixed it for me. Thanks!

[LentoYe]

Hey dude, the same problem confuses me alot. I can't see mf-manifest.json, either.
Did u just set manifest like this?

             manifest: {
                    filePath: './',
                    fileName: 'mf-manifest.json',
                },

[SharmaTushar]

I'm using rspack with configuration quite similar to this one. My types get generated (take forever on every little change to code), I can access /mf-manifest.json on both host and MFE. I see a .dev-server.zip in my MFE's dist folder, but the types are never copied over to host and I don't see a @mf-types folder anywhere.

[jethoo]

It does not work on https. When linked with http url, @mf-types is created in host

[manvydas-tbol]

If someoene is using webpack at the moment and plans to implement microfrontend architecture, should they always use Module Federation 2.0 and not webpack's built in module federation?

[zhoushaw]

Yes, you can use module federation 2.0 directly

[zhangHongEn]

@zhoushaw @ScriptedAlchemy
https://github.com/zhangHongEn/module-federation-vite/blob/f11adc79f203ba5d7a0622a460c74a6f5e557489/packages/module-federation-vite/src/index.js#L86
How can I wait for remote to be ready?
I tried "hooks.lifecycle.init.once" and "initializeSharing()" but it didn't work

[zhangHongEn]

I need to ensure that shareScopes is a singleton. My current code is remote1 + a rust host. If they both reference remote3 at the same time, an error will be reported.
Error: Container initialization failed as it has already been initialized with a different share scope

[zhangHongEn]

I originally wanted to ensure that all remotes were ready when I acquired loadShare, but I found that loadShare already had this logic built in. I now have another problem, how can I merge the first shared parameter of init with the shared of runtimeInit https://github.com/zhangHongEn/module-federation-vite/blob/47d6f304c8dc3fd51542f2f0ac0ca569fdea7613/packages/module-federation-vite/src/index.js#L81

You can look at the code I pointed out. I think it may be caused by multiple shared instances. Or it may be a bug in @module-federation/runtime itself?

[zhangHongEn]

「how can I merge the first shared parameter of init with the shared of runtimeInit」Can you describe the problem in more detail?
@zhoushaw
vite project npm run dev
rust project npm run start
You can reproduce the problem that shareScopes is not a singleton. This should be the logic I need to handle in init.

[2heal1]

@zhangHongEn hey , I want to make sure the reproduce infos :

1. repo : https://github.com/zhangHongEn/module-federation-vite
2. branch: vite-implement ?

Is the info correct ?

[zhangHongEn]

@zhangHongEn hey , I want to make sure the reproduce infos :

1. repo : https://github.com/zhangHongEn/module-federation-vite
2. branch: vite-implement ?

Is the info correct ?

solved

[darktasevski]

@zhoushaw Is there a migration guide from the WMF to MF 2.0? I can't seem to find anything about migration on the new website, nor if the Webpack MF is compatible with MF 2.0. I have a federation of around 20 MF applications, and we'll probably benefit from some of the newly introduced features, but I don't see a clear path to start the migration.