Vite 8 + Module Federation: How to handle shared dependencies version conflicts?

[Syaptiyan]

Problem

I am building a micro-frontend architecture with Vite 8 and Module Federation. Different micro-apps use different versions of the same dependency.

Architecture

Host App with multiple Micro Apps, each potentially using different React versions.

Current approach

Using @originjs/vite-plugin-federation with shared dependencies.

Problems

1. Version conflicts - Micro-apps use different React versions
2. Duplicate dependencies - React loads multiple times
3. Type conflicts - TypeScript types do not match across versions
4. Bundle size - Each micro-app bundles its own dependencies
5. Runtime errors - Hooks break when React versions mix

What I tried

1. Shared config - Forces all to use same version
2. Singleton - Only loads one version, breaks others
3. External dependencies - Load from CDN, but version issues remain
4. Import maps - Browser-level version management

Questions

1. How do you handle version conflicts in Module Federation?
2. Should I force all micro-apps to use the same React version?
3. Is there a way to run multiple React versions simultaneously?
4. Should I use a different micro-frontend approach?
5. How do you handle TypeScript types across different versions?

Environment

• Vite 8
• @originjs/vite-plugin-federation
• React 18/19
• TypeScript 5

Any insights on micro-frontend architecture with Vite would be appreciated.

[apoorva-01]

Two separate things going on here, and the React one is non-negotiable.

You can't run two React versions in the same page and share components between them. Hooks resolve through a single module-level dispatcher, so the moment a component from remote A (React 18) renders inside host B (React 19), that dispatcher is wrong and you get "invalid hook call" and everything falls apart. No config makes that safe. react and react-dom have to be singleton: true on one agreed version across the host and every remote. Treat it as a hard constraint, not a preference.

Second thing: @originjs/vite-plugin-federation is community-maintained and its shared-dependency negotiation is weak, which is where most of the "React loads twice" pain comes from. The Module Federation team now ships an official Vite plugin, @module-federation/vite, and it supports Vite 8 (peer range is ^5 || ^6 || ^7 || ^8). It does proper runtime shared-version resolution, so singletons actually stay single. I'd switch to it.

Rough shape:

import { federation } from '@module-federation/vite'

federation({
  name: 'host',
  remotes: { /* ... */ },
  shared: {
    react: { singleton: true, requiredVersion: '19.0.0' },
    'react-dom': { singleton: true, requiredVersion: '19.0.0' },
  },
})

On the TS types: pin one React version in the workspace root so every package resolves the same @types/react. Mismatched React types across remotes is the same root cause as the runtime problem, and one version fixes both.

So: force one React version, mark it singleton, let the official plugin handle the sharing. "Multiple React versions live at once" isn't a thing worth chasing, that road only ends in broken hooks.

[Syaptiyan]

@apoorva-01 Great explanation on the singleton constraint! But this raises a deeper architectural question:

What happens in this scenario?

// Host App (React 19)
const RemoteA = React.lazy(() => import("remoteA/App")); // React 18
const RemoteB = React.lazy(() => import("remoteB/App")); // React 19

function Host() {
  return (
    <>
      <RemoteA /> {/* Uses React 18 hooks dispatcher */}
      <RemoteB /> {/* Uses React 19 hooks dispatcher */}
    </>
  );
}

With singleton: true, only ONE React version loads. But:

1. RemoteA was compiled against React 18 types and uses ReactDOM.render() (legacy API removed in React 19)
2. RemoteB uses React 19 features like use() hook and Server Components

If we force singleton to React 19, RemoteA breaks because it expects React 18 API. If we force React 19, RemoteB can not use new features.

The real question: Is there a viable strategy for gradual migration across micro-frontends where:

• Some remotes are stuck on React 18 (legacy)
• Some remotes need React 19 features
• They must coexist in the same page

Or is the only answer: "upgrade everything at once, or dont bother with Module Federation"?

Also, regarding @module-federation/vite - does it handle the build-time version negotiation, or only runtime? Because if RemoteA is built with React 18 and RemoteB with React 19, the shared chunks will have incompatible internals regardless of runtime singleton config, right?

[Saakhavat-Prime]

Coexistence problem: The issue isn't the React version itself, it's that and as JSX get reconciled by Host's React instance. That's baked into how JSX composition works — no config changes it. So singleton: true can't work across major versions, and without it you get the double-dispatcher crash.
Real fix: Drop JSX-level composition for mismatched versions. Two working patterns:

DOM mount isolation — remote exposes mount(container, props) / unmount(container), host calls it via useEffect, each remote runs its own ReactDOM.createRoot(). Fully separate React trees, communicate via props/callbacks or DOM events, not context. This is how single-spa handles it.
Web Component wrapping — wrap each remote in a custom element so the host only touches a DOM node, never a React component.

Tradeoff: no shared Context/Suspense across remotes, no passing JSX children directly.
Build-time vs runtime: @module-federation/vite only does runtime negotiation — it picks which built module to hand out, it doesn't rewrite code. So if RemoteA calls ReactDOM.render() (removed in 19) and singleton hands it React 19, it breaks regardless of the plugin. Singleton assumes code compatibility, not just module identity — that gap has to be fixed in code first.
Migration path: Isolate legacy remotes via DOM mounting (no singleton) → once a remote drops React 18-only APIs, move it into the singleton group → repeat until everything converges. Classic strangler-fig migration, not a permanent multi-version setup.