0Pricing
Micro Frontends Architecture with Module Federation · درس

التبعيات المشتركة وإدارة الإصدارات

تعلّم كيف يشارك Module Federation المكتبات عبر الواجهات الأمامية المصغّرة، وكيف تعمل الوحدات المفردة والتفاوض على الإصدارات، وأفضل الممارسات التي تمنع الحزم المكررة وأعطال وقت التشغيل.

التبعيات المشتركة وإدارة الإصدارات درس مجاني في Micro Frontends Architecture with Module Federation على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Micro Frontends Architecture with Module Federation، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Micro Frontends Architecture with Module Federation 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

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 App

Sharing 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 requiredVersion to align teams.
  • Keep eager only 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.

الأسئلة الشائعة

هل درس «التبعيات المشتركة وإدارة الإصدارات» مجاني؟

نعم — نص درس «التبعيات المشتركة وإدارة الإصدارات» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Micro Frontends Architecture with Module Federation، انتقل إلى CoddyKit PRO. تتضمن دورة Micro Frontends Architecture with Module Federation 4 دروس في المجموع.

ماذا ستتعلم في «التبعيات المشتركة وإدارة الإصدارات»؟

تعلّم كيف يشارك Module Federation المكتبات عبر الواجهات الأمامية المصغّرة، وكيف تعمل الوحدات المفردة والتفاوض على الإصدارات، وأفضل الممارسات التي تمنع الحزم المكررة وأعطال وقت التشغيل. تتمرن على Micro Frontends Architecture with Module Federation مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Micro Frontends Architecture with Module Federation؟

لا تُشترط خبرة سابقة. Micro Frontends Architecture with Module Federation على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «التبعيات المشتركة وإدارة الإصدارات»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Micro Frontends Architecture with Module Federation هذا؟

نعم. كل درس في Micro Frontends Architecture with Module Federation يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. Monorepos أم Polyrepos
  2. التحديات التنظيمية والحلول
  3. مستقبل Micro Frontends وFederation
  4. التبعيات المشتركة وإدارة الإصدارات
← العودة إلى Micro Frontends Architecture with Module Federation