# Module Federation 2.0 in the module-federation/core repository: runtime, manifest and dynamic types

> The core repository behind Module Federation 2.0 adds a standalone runtime, a manifest format, a runtime plugin system and generated type hints on top of the module sharing that shipped inside webpack 5. This is what the repository documents, what it leaves open, and who should adopt it.

**module-federation/core** — Module Federation is a concept that allows developers to share code and resources across multiple JavaScript applications

- Repository: https://github.com/module-federation/core
- Website: https://module-federation.io/
- Stars: 2,647 · Forks: 437
- Language: JavaScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/module-federation-core

## The gap Module Federation 2.0 is aimed at

Webpack 5 shipped module federation as a bundler feature: a container exposes modules, a remote entry loads them, and shared dependencies are deduplicated. That works while every participant is a webpack build. The problem the repository describes is what happens when the architecture grows past that. The README states that the capabilities in this repository should be considered "module federation 2.0", and that it differs from the federation built into webpack 5 by adding dynamic type hinting, a Manifest, a Federation Runtime and a Runtime Plugin System. The stated goal is that Module Federation becomes more suitable as a micro-frontend architecture in large-scale web applications.

The audience is therefore narrow and specific: teams running several independently built front ends, usually under different release cadences, who need the host to resolve remotes at runtime rather than at build time. A single application that merely wants to lazy-load a route does not need any of this. The README's own description of the concept is modest, it says Module Federation allows developers to share code and resources across multiple JavaScript applications, and that it can be used to split a monolith into a micro-front-end architecture while reusing common dependencies between modules as much as possible.

## Runtime, manifest and plugin system: what the pieces actually do

The repository is a monorepo, and the package names visible in the README's badge and in the repository scripts point at the split. The npm version badge links to @module-federation/runtime, which is the piece that runs in the browser or in Node rather than inside the bundler. That separation is the architectural move: the bundler produces containers, but loading, registering and resolving them happens through the runtime, so a host can decide at runtime which remote to pull in.

The Manifest is the second piece. The README lists it as a new feature alongside the runtime, and the repository carries a root manifest.json. A manifest gives the host a description of what a remote exposes, which is what makes runtime resolution possible without hardcoding entry URLs into the host build. The third piece is the Runtime Plugin System, which the README lists as a distinct feature. Plugins are the extension point for behaviour that would otherwise be hardcoded into the host, such as how a remote is fetched or what happens when it fails.

Dynamic type hinting is the fourth. In a federated setup the host compiles against types it does not own, and the README lists dynamic type prompt as a feature of this repository. The repository confirms the tooling exists at the package level: the README's Node.js support section mentions type generation among the categories of published packages that execute in Node.js, which is where generated remote types would come from. The Chrome Devtool is listed as a fifth feature; the README names it but does not document what it shows.

## Installing it and getting a first runtime working

The README does not contain install instructions. It points readers at the Quick Start at module-federation.io, so that page, not this repository's README, is where the canonical setup steps live. What the repository does document is the toolchain needed to work on the monorepo itself, and that is worth reading before you file an issue, because it tells you what the maintainers actually build against.

The root package.json pins the toolchain. The engines field requires Node.js ^24 and pnpm ^10, and packageManager is set to pnpm@10.28.0:

```json
{
  "engines": {
    "node": "^24",
    "pnpm": "^10"
  },
  "packageManager": "pnpm@10.28.0"
}
```

That is the contributor requirement, not the consumer requirement. The README's Node.js support section draws the line explicitly: working on the repository requires Node.js 24 and pnpm 10.28.0, while published packages that execute in Node.js, including build plugins, command-line tools, type generation, workers, and server-side runtime code, remain compatible with Node.js 20.19.5. CI builds on Node.js 24 and then installs the resulting tarballs into a clean Node.js 20.19.5 project to check the CommonJS, ES module, command-line and type entry points.

So a consumer installs from npm rather than cloning. The README's badge points at @module-federation/runtime as the published package to look for:

```bash
npm install @module-federation/runtime
```

After that, the repository is silent on the host-side API. The README does not document a createInstance call, a registerRemotes call or any other runtime entry point, and this article will not invent one. The honest next step is the Quick Start link the README gives. If you want to see the runtime exercised before committing to it, the repository's package.json exposes e2e targets that name the scenarios: e2e:runtime runs test:e2e filtered to runtime-host, and e2e:manifest:dev and e2e:manifest:prod run against 3008-webpack-host. Those filters are the closest thing to a documented reference application in the repository.

## Where federation stops being the right answer

The failure mode that matters most is version skew on shared dependencies. The README says Module Federation reuses common dependencies between modules as much as possible. That phrasing is doing real work. Sharing is a negotiation between the host's version and each remote's version, and when a remote is deployed on its own schedule, the host can end up loading a remote built against a different React or a different runtime than the one it expects. Nothing in the README describes a compatibility guarantee across independently deployed remotes, and the repository's answer to type drift is generation rather than enforcement.

The second limitation is the toolchain floor for contributors. A team that wants to patch a plugin or fix a bug in the runtime has to run Node.js 24 and pnpm 10.28.0, and the README notes that Node.js 20 no longer receives upstream maintenance even though the project keeps publishing packages compatible with 20.19.5 for legacy consumers. That is a deliberate split, and it means the runtime you ship and the runtime you debug are built under different Node versions.

The third is scope. If your application is one deployable unit, or if the only sharing you need is a component library published to a registry, federation adds a runtime resolution layer, a manifest to keep in sync, and a plugin surface you now have to reason about. A package registry gives you versioned, immutable artifacts and a lockfile. Federation gives you late binding, and late binding is exactly what you do not want when nothing needs to be bound late.

## How it differs from webpack 5's built-in federation

The most direct alternative is the module federation that already ships inside webpack 5, and the README frames the comparison itself. The built-in version covers the core features the README lists: module export, loading, and dependency sharing. What it does not have, according to the README, is dynamic type hinting, a Manifest, a Federation Runtime or a Runtime Plugin System.

The practical difference is where decisions get made. With webpack 5 federation, the host's configuration declares the remotes and the build resolves them; changing which remote a host talks to is a build concern. With the runtime in this repository, the host carries the resolution logic, which is what makes a manifest and a plugin system meaningful. If your remotes are fixed at build time and you never need to swap one without rebuilding the host, the built-in feature set is sufficient and you avoid an extra runtime dependency.

The trade-off runs the other way too. A runtime that resolves remotes is a runtime that can fail to resolve them, and the README does not document rollback behaviour, a fallback path when a manifest is unreachable, or what the runtime does when a remote entry 404s. Before adopting, that is the gap to probe: ask what happens when the manifest is stale, because in production that is the failure you will actually hit.

## Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-09-24. Releases are frequent and versioned: v2.9.1 on 2026-09-21, v2.9.0 on 2026-08-24, and v2.8.2 on 2026-08-06. The repository uses Changesets, visible as the .changeset directory at the top level and the changeset-gen.js script, which is the mechanism behind those version bumps and their changelogs. For a consumer, that means upgrade notes are generated per release rather than hand-written, and the changelog is the place to look before bumping a minor.

The licence is MIT, stated in the README's badge, in the package.json license field, and in the LICENSE file at the repository root. MIT permits commercial use and modification with the copyright notice retained; it offers no patent grant and no warranty. That is a factual description of the terms, not legal advice, and teams with patent exposure or a policy against permissive licences should route the question to their own counsel.

The upgrade cost is concentrated in the runtime boundary. Because the host resolves remotes at runtime, a runtime upgrade and a remote upgrade are independent events, and the repository's own compatibility testing targets the published packages rather than a live federated deployment. The README describes CI installing built tarballs into a clean Node.js 20.19.5 project and building a clean TypeScript project with both Webpack and Rspack. That covers entry points and bundler compatibility. It does not, from what the README says, cover a host on one runtime version talking to a remote on another.

## Conclusion

Adopt module-federation/core when you are splitting several independently deployed JavaScript applications and you need a manifest, a runtime plugin system or generated types that webpack 5's built-in federation does not provide. Do not adopt it to share a handful of components between two bundles, and do not expect the README to walk you through a migration. Verify first that your bundler and framework combination appears in the repository's own examples and e2e filters, since those are the paths the project exercises, and check the package you intend to install against the Node.js 20.19.5 floor the README states for published Node.js packages.

## FAQ

### What is Module Federation used for?

The README describes it as a concept that lets developers share code and resources across multiple JavaScript applications, and says it can be used to split a monolithic application into a micro-front-end architecture while reusing common dependencies between modules as much as possible. This repository adds a runtime, a manifest, runtime plugins and dynamic type hints on top of that.

### What are the disadvantages of Module Federation?

The README does not list disadvantages. The visible trade-offs are structural: sharing dependencies between independently deployed remotes means version skew is possible, the runtime resolves remotes late so a failed resolution is a runtime failure rather than a build error, and the README does not document rollback or fallback behaviour when a manifest or remote entry is unavailable.

### Can you use Module Federation without webpack?

The README compares this repository's capabilities to the federation built into webpack 5 and describes the runtime, manifest and plugin system as additions rather than replacements, so the bundler still produces the containers. The README's Node.js support section states that CI builds a clean TypeScript project with both Webpack and Rspack, which shows Rspack is a supported build path.

## Sources

- [License: MIT](https://github.com/module-federation/core/blob/main/LICENSE)
- [module-federation/core on GitHub](https://github.com/module-federation/core)
- [Project website](https://module-federation.io/)
- [README](https://github.com/module-federation/core/blob/main/README.md)
- [Releases](https://github.com/module-federation/core/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/module-federation-core