Single Runtime Plugin Example

This example demonstrates how the Module Federation single runtime plugin works to ensure shared dependencies use a single runtime instance when a remote application loads components from its host.

Running the Demo

1. Start both applications:

   # In host directory
   npm start # Runs on port 3010
   
   # In remote directory
   npm start # Runs on port 3011

What to Observe

On HOST (port 3010)

When you browse to localhost:3010, observe the Runtime Information section:

• Notice that REMOTE's module is using host_partial.js instead of remoteEntry.js
• This happens because REMOTE lists HOST as a remote, and to avoid loading conflicting runtimes from the same build (HOST), the plugin switches to using the partial bundle
• The partial bundle ensures HOST's components use the host's runtime when loaded in REMOTE

On REMOTE (port 3011)

When you browse to localhost:3011, observe the Runtime Information section:

• When loading HOST's remote components, it uses the standard remoteEntry.js
• This is because HOST is not the host in this context
• Since there's no host/remote pattern here, HOST needs its full standalone runtime to operate

How it Works

The single runtime plugin prevents runtime conflicts by:

1. When a remote app loads components from its host:

   • The plugin detects this pattern and switches to using {hostName}_partial.js
   • This ensures the remote uses the host's runtime instead of loading a duplicate
   • Prevents conflicts in singleton modules and shared dependencies

2. When loading other remotes:

   • Uses the standard remoteEntry.js
   • No runtime conflict possible since it's loading from a different build

Shared Dependencies

Both apps share:

• React (singleton)
• ReactDOM (singleton)
• Lodash (version matching)

The single runtime plugin ensures these shared dependencies maintain their singleton status by preventing duplicate runtime loading from the same build. Also prevents collisions caused by loading 2 runtimes from the same build at once