Federation Wizards
Open source Node.js Built for MF 2.0 (`@module-federation/enhanced`)

Tame Module Federation 2.0 without the ceremony.

Federation Wizards is a CLI (fwiz) + local dashboard that centralizes configuration, orchestrates local dev, and makes shared dependency conflicts visible—so teams ship micro-frontends with less friction.

Get started Read the roadmap
Designed around MF 2.0 vocabulary: host/remote, manifest, share scope, singleton, runtime plugins.
Why

The pain is real (and very repeatable)

These are the problems we see across MF 2.0 setups: duplicated config, chaotic local dev, and shared dependency collisions that only appear at runtime.

Config overhead

Duplicate federation plugin configs, hard-coded remote URLs, and drift between host/remote apps.

Centralize into `fwiz.config.yaml` instead of repeating `ModuleFederationPlugin` setup per app.

Local dev chaos

Starting many servers manually, proxy/CORS edge cases, and HMR breaking across remotes.

`fwiz dev` is designed to orchestrate hosts + dependent remotes with consistent ports and logs.

Dependency hell 2.0

Share-scope collisions and singleton/version mismatches (e.g. React 17/18) causing runtime crashes.

`fwiz analyze-shared` surfaces conflicts and suggests safer sharing defaults for MF 2.0.

What

What you get

A CLI-first toolchain with an optional local dashboard. Focus: central config, orchestration, and MF-specific visibility.

Central config

`fwiz.config.yaml` as the source of truth.

Generate bundler federation configs (adapters planned).

Dev orchestrator

`fwiz dev` starts a host and its dependent remotes.

Unified logs, port handling, and local-first workflows.

Shared deps analyzer

`fwiz analyze-shared` scans packages and reports conflicts.

Suggests singleton/strictVersion patterns to reduce surprises.

Manifest + registry

Versioned manifests and a publishing workflow.

Designed around MF 2.0 manifests and dynamic remote discovery.

CI validation

`fwiz validate` checks compatibility and breaking changes.

Built for fast, pipeline-friendly checks.

Dashboard

A local UI for graph + runtime visibility.

Hosts → Remotes → Shared + logs/telemetry (planned).

How

How it works (conceptual)

The workflow is designed to centralize what teams otherwise re-implement per repo, while staying compatible with MF 2.0 concepts like manifests and runtime plugins.

Flow
Developer → fwiz CLI
fwiz CLI → fwiz.config.yaml
fwiz CLI → config engine → bundler configs
fwiz CLI → dev orchestrator → hosts/remotes
hosts/remotes → telemetry/logs → dashboard
fwiz CLI → validator → CI
Diagram intentionally plain so it stays portable for GitHub Pages.
Mermaid (copy/paste)
flowchart LR
  Developer --> fwizCLI
  fwizCLI --> configYaml
  fwizCLI --> engine
  engine --> bundlerConfigs
  fwizCLI --> devOrchestrator
  devOrchestrator --> hostsRemotes
  hostsRemotes --> runtimeTelemetry
  runtimeTelemetry --> dashboard
  fwizCLI --> validator
  validator --> ciPipeline
You can later render this via a Mermaid integration if desired.
Commands

Spellbook (CLI-first)

A compact set of commands intended to cover init → dev → analyze → validate → visibility.

Install
# planned (when published)
npm i -g fwiz

# meanwhile (from repo)
npm i
npm run fwiz -- --help
The global install line is a placeholder until a package exists.
$ fwiz init
Generate a starter `fwiz.config.yaml` (hosts/remotes/shared/environments).
Output: Prints what was created and what was detected in the repo.
$ fwiz dev [project]
Start a host/remote and orchestrate dependent remotes in parallel.
Output: Prints started URLs, timings, and aggregated logs.
$ fwiz build
Build federation apps with consistent config generation.
Output: Reports output artifacts and (optionally) manifest paths.
$ fwiz analyze-shared
Analyze dependency versions and share-scope risks across projects.
Output: Emits a human report and a machine-readable JSON summary.
$ fwiz validate
Validate manifests/shared versions and detect breaking changes in CI.
Output: Exits non-zero on incompatibilities; prints actionable diffs.
$ fwiz dashboard
Start the local dashboard for visibility and troubleshooting.
Output: Opens a local URL for the graph + logs view.
Roadmap

Honest scope: Now / Next / Later

Everything here is phrased as planned unless implemented. The goal is to reduce MF 2.0 friction, not to replace general-purpose monorepo tooling.

Now (MVP)
  • CLI skeleton + config parsing (`fwiz init`, `fwiz dev` foundations).
  • Dev orchestrator with process management and sane defaults.
  • Shared dependency analyzer with conflict reporting.
  • Manifest tooling + early registry workflow.
Next
  • CI validation (`fwiz validate`) with breaking-change detection.
  • Dashboard: graph view (Hosts → Remotes → Shared) + better logs.
Later
  • Type hints sync + `fwiz mock-remote` stubs.
  • More adapters + examples across frameworks/bundlers.
Community

Help us make MF 2.0 calmer

Built with teams shipping Module Federation 2.0 in mind. Contributions that improve DX, correctness, and testability are especially welcome.

How to help
  • Open issues with a reproducible MF failure mode (host/remote/share scope/manifest).
  • Propose features with constraints (what it solves, what it won’t do).
  • Send PRs with tests and clear docs for CLI behavior.
FAQ
Is this tied to a framework?
No. The goal is framework-agnostic MF workflows.
Webpack / Rspack / Vite?
Adapters are planned; the central config + validation are the core.
Will it replace Nx/Turbo?
No. It’s complementary and MF-focused (orchestration + visibility).