Module Federation Examples: A Reference Repository of Webpack 5 Micro-Frontend Patterns

What the Repository Is and Who It Is For

module-federation-examples is a reference collection, not an installable package. Its purpose is to provide working, runnable demonstrations of Webpack 5's Module Federation capability across a range of scenarios: a basic host-remote setup, bidirectional sharing, different React versions coexisting in one page, server-side rendering, CSS isolation, federated libraries loaded from CDN, and multi-framework setups using Angular, Vue 3, Svelte, and Solid.

The repository is maintained by the creators of Module Federation and is intended as the canonical source of example code. Engineers who are adopting Module Federation for the first time, or who are debugging a specific integration problem, can use it to find a working reference for their use case.

How Module Federation Works

Module Federation is a Webpack 5 feature that lets separately built and deployed JavaScript applications share code at runtime without bundling it together at build time. A host application can load a remote module from another application's deployed bundle, receive React components, utility functions, CSS, JSON, WASM, or any other Webpack-processable file type, and render it as if it were a local import.

The shared code is loaded lazily from the remote's URL, which means the host does not need to know the remote's internal implementation at build time. This makes it possible to deploy the host and remote independently and release the remote without redeploying the host. The README states explicitly: Module Federation is not a JavaScript-only or React-only feature.

Each application declares what it exposes and what it consumes in its Webpack configuration. The `exposes` key lists modules other applications can load; `remotes` lists the external applications the current app can pull from; `shared` lists dependencies both sides should treat as singletons to avoid loading multiple copies of React or other libraries.

Repository Structure and How to Navigate It

The repository root is a pnpm workspace. Each subdirectory is a self-contained example with its own `package.json`. The top-level directory listing includes over 60 example folders, organized by pattern: `basic-host-remote/`, `bi-directional/`, `css-isolation/`, `federated-css/`, `federated-library-from-cdn/`, `different-react-versions-16-17/`, `angular-universal-ssr/`, `module-federation-vite-react/`, `module-federation-vite-angular/`, `module-federation-vite-svelte/`, `module-federation-vite-vue3/`, and many others.

A full list is available in `output.md` at the repository root. The `advanced-api/` folder covers less common Module Federation API patterns. The `cloud/` directory contains examples intended for cloud deployment via Zephyr Cloud.

Some examples are marked proprietary and must be removed before the workspace install will succeed. The README is explicit about this requirement.

Running Examples Locally

To run any example, first ensure pnpm is installed. Then remove all proprietary example directories, install from the repo root, and start the example of your choice:

pnpm i

After that, navigate to the example directory and start it:

pnpm start

Some examples use a different command. The README notes that alternatives like `dev` or `serve` may be needed for specific examples. The workspace uses pnpm 10 as the package manager, pinned in `packageManager` in `package.json`.

The root `package.json` overrides `@playwright/test` to `1.58.2` and `playwright` to `1.58.2` across the workspace, which affects any example that includes end-to-end tests. The workspace also overrides `@types/react` to `18.3.10` and `@types/react-dom` to `18.3.0`, so examples using different React versions share consistent type definitions.

What Module Federation Is Not and Where It Falls Short

Module Federation does not handle deployment coordination, versioning contracts, or rollback between host and remote. If a remote is redeployed with a breaking API change while the host is still running, requests for the old module will fail or return incompatible code. Teams that need automatic version management, dependency pinning between remotes, or multi-artifact deployment pipelines need tooling beyond Webpack itself.

The repository also has no mechanism for monitoring which version of a remote a host is currently consuming in production. This is a real operational gap in micro-frontend architectures that Module Federation on its own does not address.

Furthermore, the pnpm workspace approach means that local development runs all remotes simultaneously on separate ports. This is straightforward for small teams, but coordinating dozens of independently deployed remotes in CI/CD requires additional tooling.

Module Federation vs Iframes and Web Components

Iframes are the oldest approach to isolating independently deployed frontend applications. They provide complete JavaScript and CSS isolation, but at the cost of communication complexity (postMessage), layout constraints, and duplicate resource loading. Module Federation allows remotes to share dependencies like React, which avoids loading the library twice, but it means the host and remote must coordinate on shared dependency versions.

Web Components offer a standards-based way to ship isolated UI elements. They do not require a build tool, work across frameworks, and are supported natively in modern browsers. Module Federation, by contrast, is a build tool feature specific to Webpack (and Vite via the `@module-federation/vite` plugin). Teams already invested in Webpack will find Module Federation more natural; teams that prefer framework-agnostic, build-tool-independent components should evaluate Web Components first.

Zephyr Cloud, mentioned in the README as a deployment partner, provides automated deployment and version management specifically for Module Federation applications. It integrates directly into the build and supports Webpack, Vite, and Rspack.

Maintenance Status and License

The repository is MIT licensed and not archived. The last push was on 2026-07-08. There are no GitHub releases; examples are updated in place. The workspace root `package.json` carries the name `module-federation-examples-root` with version `0.0.0`, marking it as a non-published workspace root.

The repository lists an extensive set of companies using Module Federation in the README, including major technology and retail organizations. These are listed as self-reported adopters in the README text, not independently verified by the repository maintainers.

Editorial conclusion

This repository suits engineers who are learning Module Federation or troubleshooting a specific integration pattern. The runnable examples cover a wide range of configurations, and having the creators maintain it means the patterns reflect current best practices. It is not a library to install: there is no npm package and no API. Teams that need the full Universe plugin set, versioning, or cloud deployment tooling should look at the module-federation/universe repository and Zephyr Cloud. Before running any example, remove the proprietary example directories first; the README states this is required for `pnpm i` to succeed at the repo root.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. module-federation/module-federation-examples on GitHub
4. Project website
5. README