Configuring Host and Remote React Apps

The remote application adds ModuleFederationPlugin to its webpack config with three key properties: name (unique identifier, e.g., "buttonApp"), filename ("remoteEntry.js" — the manifest output), and exposes (a map from public name to source file path).

The exposes configuration maps a public module path to a local file: { './Button': './src/Button' }. This means the host can import 'buttonApp/Button' and receive the component from ./src/Button.tsx. You can expose multiple components, utilities, or even entire pages.

The shared property tells Module Federation which modules should be shared across host and remote rather than duplicated. For React: shared: { react: { singleton: true, requiredVersion: deps.react }, 'react-dom': { singleton: true } }. singleton:true prevents multiple instances from loading simultaneously.

The host application's ModuleFederationPlugin config includes a remotes property: { buttonApp: 'buttonApp@http://localhost:3001/remoteEntry.js' }. The key is the import namespace, the value is the remote's name and URL combined with @ — telling Webpack where to fetch the remote at runtime.

In the host's React code, import the remote component with dynamic import: const Button = React.lazy(() => import('buttonApp/Button')). The import path matches the remote's namespace and the exposed module name. React.lazy makes the import code-split and asynchronously loaded.

Since remote modules are loaded asynchronously, always wrap the lazy-imported remote component in a Suspense boundary: Suspense fallback=Loading... /. The fallback renders while Module Federation fetches remoteEntry.js and the component chunk from the remote URL.

React's hooks (useState, useContext, useEffect) depend on a single internal React instance to track component state. If both the host and remote load their own copy of React, hooks will throw "invalid hook call" errors. singleton:true forces them to share one React instance, resolving this class of bugs entirely.

When host uses react@18.2.0 and remote uses react@18.3.0, Module Federation's shared scope negotiates which version to use. With singleton:true and requiredVersion, it typically uses the higher version if compatible. Setting requiredVersion: '>=18.0.0' instead of a pinned version allows flexible version ranges.

TypeScript doesn't know about remote modules at compile time, so imports like import('buttonApp/Button') will throw type errors without declarations. Use @module-federation/typescript or manually create .d.ts files that declare the module types, giving you type safety for remote component props.

Run both apps simultaneously: the remote on port 3001 and the host on port 3000. Open the host — its Module Federation runtime will fetch http://localhost:3001/remoteEntry.js, discover the Button module, download its chunk, and render it inside the host app as if it were a local component.

In production, replace localhost:3001 with the deployed remote's URL. A common pattern is to use an environment variable for the remote URL so CI/CD can inject the correct URL per environment: buttonApp: 'buttonApp@' + process.env.BUTTON_REMOTE_URL + '/remoteEntry.js'.

Why must React be configured as a singleton in Module Federation's shared configuration?

Configuring Module Federation requires ModuleFederationPlugin on both remote (with name, filename, exposes) and host (with remotes). Consume remote components via React.lazy + dynamic import wrapped in Suspense. React and React DOM must be shared singletons to prevent multiple-instance hook errors. TypeScript declarations and environment-variable remote URLs complete a production-ready setup.