التبعيات المشتركة وإدارة الإصدارات
تعلّم كيف يشارك 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 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.
الأسئلة الشائعة
هل درس «التبعيات المشتركة وإدارة الإصدارات» مجاني؟
نعم — نص درس «التبعيات المشتركة وإدارة الإصدارات» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 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 يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- Monorepos أم Polyrepos
- التحديات التنظيمية والحلول
- مستقبل Micro Frontends وFederation
- التبعيات المشتركة وإدارة الإصدارات