Shared Dependencies & Version Management
Learn how Module Federation shares libraries across micro frontends, how singletons and version negotiation work, and the best practices that prevent duplicate bundles and runtime breakage.
Shared Dependencies & Version Management is a free Micro Frontends Architecture with Module Federation lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Micro Frontends Architecture with Module Federation learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Sharing Matters
In a Module Federation setup every remote can bundle its own copy of react, react-dom, or a design system. Without coordination, a single page may load three copies of React.
Shared dependencies let independently deployed apps agree on a single instance of a library at runtime, cutting payload and avoiding state bugs.
The shared Key
Both host and remotes declare a shared block in their ModuleFederationPlugin config. Webpack then negotiates which version actually loads.
new ModuleFederationPlugin({
name: 'host',
shared: {
react: { singleton: true },
'react-dom': { singleton: true }
}
})Singletons Explained
singleton: true forces one and only one copy across the whole app. This is essential for libraries that hold internal state, like React (hooks) or a router.
Without it, two React instances cause the dreaded Invalid hook call error.
Version Negotiation
Each shared module declares a requiredVersion. At load time Module Federation picks the highest compatible version among all that are offered.
shared: {
react: {
singleton: true,
requiredVersion: '^18.2.0'
}
}Strict Version Mismatch
When a remote needs a version incompatible with the loaded singleton, Module Federation logs a warning and uses the existing one. With strictVersion: true it instead throws, surfacing the mismatch early.
shared: {
react: { singleton: true, strictVersion: true, requiredVersion: '18.2.0' }
}Eager vs Lazy Sharing
By default shared modules load asynchronously, which requires a bootstrap entry. Setting eager: true bundles the dependency into the initial chunk so no async boundary is needed.
Use eager only for the host shell; eager everywhere defeats the purpose of sharing.
shared: {
react: { singleton: true, eager: true }
}The bootstrap Pattern
Because shared modules resolve asynchronously, the standard pattern splits the entry into index.js (just an import) and bootstrap.js (the real app). This defers execution until the share scope is ready.
// index.js
import('./bootstrap');
// bootstrap.js
import App from './App';
// ... mount AppSharing a Design System
A shared component library should usually be a singleton too, so theming context and CSS-in-JS instances are not duplicated.
shared: {
'@acme/ui': { singleton: true, requiredVersion: '^3.0.0' }
}Auto-Sharing from package.json
Instead of listing versions by hand, you can pass an array and let the plugin read versions from package.json. Tools like the Module Federation Enhanced plugin can even auto-share all dependencies.
shared: ['react', 'react-dom', 'react-router-dom']Diagnosing Duplicate Copies
To confirm sharing works, inspect the Network tab: you should see one vendor chunk for the shared lib. Bundle analyzers and the runtime share scope (__webpack_share_scopes__.default) help debug.
Best Practices Summary
- Singleton for stateful libs (React, router, stores).
- Set
requiredVersionto align teams. - Keep
eageronly on the host shell. - Audit bundles regularly for accidental duplicates.
Quick Check
Which option ensures only one instance of React loads across all micro frontends?
Recap
You learned how Module Federation shares dependencies: singletons for stateful libs, version negotiation via requiredVersion/strictVersion, eager vs lazy loading, and the bootstrap pattern. Proper sharing slashes bundle size and prevents subtle runtime bugs.
Frequently asked questions
Is the “Shared Dependencies & Version Management” lesson free?
Yes — the full text of “Shared Dependencies & Version Management” is free to read here on the web, and the Micro Frontends Architecture with Module Federation course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Micro Frontends Architecture with Module Federation course, upgrade to CoddyKit PRO.
What will I learn in “Shared Dependencies & Version Management”?
Learn how Module Federation shares libraries across micro frontends, how singletons and version negotiation work, and the best practices that prevent duplicate bundles and runtime breakage. You practise Micro Frontends Architecture with Module Federation with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Micro Frontends Architecture with Module Federation?
No prior experience is required. Micro Frontends Architecture with Module Federation on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Shared Dependencies & Version Management” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Micro Frontends Architecture with Module Federation lesson?
Yes. Every Micro Frontends Architecture with Module Federation lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Monorepos vs. Polyrepos
- Organizational Challenges & Solutions
- Future of Micro Frontends & Federation
- Shared Dependencies & Version Management