تهيئة التبعيات المشتركة

Without coordination, a host and each remote would each bundle their own copy of React, Lodash, and other libraries. Users would download the same code many times.

The shared option solves this.

The shared key in ModuleFederationPlugin tells webpack which dependencies should be loaded once and reused across federated apps at run time.

The simplest form lists package names as an array. Webpack then negotiates a single shared instance at run time.

The object form gives fine-grained control per dependency, such as marking it required or singleton.

singleton: true forces every app to use ONE instance of the library. This is essential for React, whose hooks break if two copies load at once.

Each app declares a requiredVersion. At run time Module Federation picks the highest version that satisfies everyone. If versions are incompatible, it warns or falls back.

eager: true bundles the shared dependency into the initial chunk instead of loading it asynchronously. Useful for the host shell but increases initial bundle size.

To avoid hardcoding versions, you can derive them from your dependencies, keeping shared config in sync with what you actually install.

strictVersion: true makes Module Federation throw instead of falling back when no compatible version is found — surfacing mismatches early during testing.

Watch out for:

• Forgetting singleton on React, causing hook errors
• Mismatched major versions across remotes
• Overusing eager, bloating the first load

Open the browser network tab: if React loads only once across host and remotes, sharing is working. The webpack build log also reports shared-module resolution.

Test your shared-dependency knowledge.

You configured shared dependencies:

• shared avoids duplicate libraries across apps
• Use the object form for per-package control
• singleton is critical for React and React-DOM
• requiredVersion drives run-time negotiation
• Use eager and strictVersion deliberately

Good sharing keeps federated apps fast and conflict-free.