New and Improved Module Federation Experience with Nx

Nx 21 saw the introduction of many new and exciting features. Continuous Tasks was one such feature that I found particularly exciting because of what it could mean for the Developer Experience (DX) with Module Federation.

However, before even being able to contemplate that, a different feature needed to be completed first: the ability to use Module Federation with Nx’s Inferred Tasks.

Inferred Tasks with Module Federation

We have introduced three new Rspack Plugins for Module Federation that can be used with Nx.

• NxModuleFederationPlugin: Gathers information from the Nx Workspace to correctly configure rspack.ModuleFederationPlugin
• NxModuleFederationDevServerPlugin: Used to handle the static-serving of non-dev remotes for CSR applications
• NxModuleFederationSSRDevServerPlugin: Used to handle the static-serving of non-dev remotes for SSR applications

These are true Rspack Plugins that should be added to the plugins: [] of an rspack.config file.

Their intention is to replace withModuleFederation helpers and module-federation-dev-server executors we used to provide the Nx Module Federation Experience previously.

With these plugins, we can now set up a very standard rspack.config file that can be used with the @nx/rspack/plugin Inference Plugin - or you could even just run rspack build or rspack serve.

Not only does this mean that the config files that we create for your Module Federation projects are now compliant with the underlying tooling, but it has enabled us to take full advantage of Continuous Tasks.

Continuous Tasks with Module Federation

This is where things get interesting. Continuous Tasks in Nx allows for tasks to depend on tasks that may not end. The Nx Module Federation Experience has always relied on the serving of multiple applications.

Previously, you would run nx serve shell --devRemotes=remote1 where shell is your host application and remote1 is the remote application that you or a feature team would be currently working on to allow for HMR with remote1.

Under the hood this would start up the webpack-dev-server for both shell and remote1.

However, it always felt slightly strange for individual contributors on feature teams to be told they cannot run “their" application by simply running nx serve remote1 .

Well, now they can!

With Continuous Tasks and the new NxModuleFederationDevServer plugins, we can generate remote applications that dependsOn["shell:serve"].

Running nx serve remote1 will serve both remote1 and shell!

The NxModuleFederationDevServer plugin for the shell application will check which remotes are already running and simply ignore them - serving only the remotes that are not already served.

Getting Started with the New Nx Module Federation Experience

1. Create a new Nx Workspace

2. Add the @nx/react Plugin

3. Generate Host and Remote Applications

4. Serve the Remote Application for Development

npx nx serve remote1

With the new Terminal UI you can very easily see the logs for each application in specific frames also.

Further Reading

• Module Federation and Nx
• Nx Module Federation Technical Overview
• 🧠 Nx Docs
• 👩‍💻 Nx GitHub
• 💬 Nx Official Discord Server
• 📹 Nx Youtube Channel