Skip to content

Module Federation Interview Questions

These Module Federation interview questions cover host/remote apps, shared dependencies, versioning, and Webpack 5 runtime integration.

Module Federation Interview Overview

Module Federation lets separately deployed JavaScript applications share code at runtime: a host can dynamically import exposed modules from remotes over the network. Webpack 5 built this into the container plugin model, enabling microfrontend architectures without duplicating entire frameworks in every bundle.

Interviews test host vs remote configuration, shared singleton dependencies (React), version negotiation, failure modes when a remote is down, and how Module Federation differs from npm packages or iframes.

Module Federation Interview Cheatsheet

Quick answers you can expand in a real interview.

Topic Short answer
Host Consumes remotes; orchestrates which federated modules load.
Remote Exposes modules via ModuleFederationPlugin exposes map.
shared Dedupes react/react-dom as singletons across apps.
exposes './Widget': './src/Widget' maps public path to file.
remoteEntry.js Manifest the host fetches to wire remote containers.
Version range requiredVersion in shared avoids incompatible duplicates.

15 Module Federation Interview Questions with Answers

Use the short version first, then offer trade-offs if the interviewer wants depth.

1. What is Module Federation in Webpack 5?

Module Federation is a built-in mechanism for loading JavaScript modules from another build at runtime. Each app can expose selected modules and declare remotes it consumes. Webpack generates a remoteEntry.js container that negotiates shared dependencies, enabling independent deploys with on-demand loading.

2. What is the difference between a host and a remote?

A remote exposes federated modules through ModuleFederationPlugin exposes and publishes remoteEntry.js. A host lists remotes in its federation config and dynamically imports exposed paths like remoteApp/Widget at runtime. One app can be both host and remote in a federated graph.

3. Why is the shared configuration critical for React microfrontends?

Without shared singletons, each remote bundles its own React, breaking hooks and context. Configure shared react as a singleton with requiredVersion ^18.0.0 so one instance loads. Version mismatches fall back or warn depending on strictVersion—plan aligned React versions across teams.

4. What is remoteEntry.js?

remoteEntry.js is the container entry file a host loads to register the remote's module map and shared scope. It must be reachable at a stable URL (CDN or app origin). Host webpack config references remotes as name@URL/remoteEntry.js. Cache bust via filename hashing strategies carefully so hosts pick up remote updates.

5. How do you expose a component from a remote?

In the remote webpack config: exposes: { "./Button": "./src/Button" }. The host imports import("remoteName/Button") after remotes are configured. Use dynamic import() so the chunk loads asynchronously. TypeScript may need module federation type declarations for remote modules.

6. What happens if a remote fails to load at runtime?

Network errors or deployment outages cause dynamic import failures. Implement error boundaries, retry logic, and fallback UI in the host. Version skew can also break runtime if APIs change without compatibility. Feature flags and contract tests between teams reduce production surprises.

7. How does Module Federation differ from publishing an npm package?

npm packages install at build time and ship inside the host bundle—updates require host redeploy. Federation loads code at runtime from a URL, enabling independent deploy cadence. npm suits stable libraries; federation suits product teams owning vertical slices with shared shell integration.

8. Compare Module Federation with iframe-based microfrontends.

Iframes isolate CSS and JS completely but hurt integration—routing, accessibility, and shared state are harder. Federation shares one DOM and can share design system packages with proper shared config but requires discipline to avoid CSS collisions (Shadow DOM, CSS modules, or conventions).

9. What is requiredVersion and strictVersion in shared deps?

requiredVersion documents semver compatibility for a shared package. strictVersion: true fails if the remote's version does not satisfy the range instead of silently duplicating. Use aligned package.json versions across repos and automated checks in CI to prevent drift.

10. How do you develop Module Federation locally?

Run host and remotes on different ports with remotes pointing to localhost URLs. webpack-dev-server serves remoteEntry.js with CORS headers enabled. Tools like Nx module federation helpers orchestrate serve-all. Hot reload works per app but cross-app HMR may need restarts when federation config changes.

11. Can Module Federation work with Vite or Rspack?

Yes—@module-federation/vite and Rspack federation plugins implement similar container concepts. APIs differ slightly from Webpack 5 but the host/remote/shared model persists. Verify plugin maturity for production features like SSR and typed remotes before committing.

12. What are common shared modules besides React?

react-dom, react-router, design system packages, state libraries, and authentication context providers are typical shared singletons. Share intentionally—over-sharing creates tight coupling. Some teams share only react/react-dom and treat feature libraries as remote-owned.

13. How does routing work in a federated shell?

The host shell owns top-level routes and lazy-loads remote modules for path prefixes—/billing/* loads billing remote routes. Remotes can export route config arrays mounted by the host router. Synchronize browser history and base paths so deep links work across deployments.

14. What testing strategies apply to federated apps?

Unit-test remotes in isolation; integration-test host with mocked remoteEntry or webpack module federation runtime stubs. Contract tests verify exposed module interfaces. E2E tests hit deployed environments with all remotes live. Visual regression on composed pages catches CSS integration issues.

15. What deployment considerations should you mention?

Remotes must deploy before or compatibly with hosts expecting new APIs. Use semantic versioning in exposed module contracts, CDN cache invalidation for remoteEntry, and monitoring for failed dynamic imports. Document breaking change process because runtime coupling replaces build-time npm locks.

Common Mistakes

  • Omitting react singleton shared config and getting invalid hook call errors.
  • Hard-coding remote URLs without environment-specific configuration.
  • No error boundary when dynamic import of a remote fails in production.
  • Assuming federation removes need for aligned dependencies and contract tests.

Key Takeaways

  • Host consumes remotes at runtime via remoteEntry.js containers.
  • Shared singletons prevent duplicate React and broken context.
  • Independent deploys need runtime failure handling and version discipline.
  • Federation trades build-time coupling for operational coordination between teams.

Pro Tip

Diagram host shell → remoteEntry URL → exposed module import—it mirrors how interviewers expect you to explain runtime wiring.