إتقان تجميع وحدات JavaScript: قوة النطاق المشترك ومشاركة التبعيات

في المشهد المتطور بسرعة لتطوير الويب، غالبًا ما يتضمن بناء تطبيقات قابلة للتطوير والصيانة اعتماد أنماط معمارية متطورة. ومن بين هذه الأنماط، اكتسب مفهوم الواجهات الأمامية المصغرة (microfrontends) زخمًا كبيرًا، مما يسمح للفرق بتطوير ونشر أجزاء من التطبيق بشكل مستقل. وفي قلب تمكين التكامل السلس والمشاركة الفعالة للكود بين هذه الوحدات المستقلة يكمن ملحق Module Federation الخاص بـ Webpack، وأحد المكونات الحاسمة لقوته هو النطاق المشترك.

يتعمق هذا الدليل الشامل في آلية النطاق المشترك ضمن تجميع وحدات JavaScript. سنستكشف ماهيته، ولماذا هو ضروري لمشاركة التبعيات، وكيف يعمل، والاستراتيجيات العملية لتنفيذه بفعالية. هدفنا هو تزويد المطورين بالمعرفة اللازمة للاستفادة من هذه الميزة القوية لتحسين الأداء، وتقليل أحجام الحزم، وتحسين تجربة المطورين عبر فرق التطوير العالمية المتنوعة.

ما هو تجميع وحدات JavaScript؟

قبل الغوص في النطاق المشترك، من الضروري فهم المفهوم الأساسي لتجميع الوحدات. تم تقديمه مع Webpack 5، وهو حل لوقت البناء ووقت التشغيل يسمح لتطبيقات JavaScript بمشاركة الكود ديناميكيًا (مثل المكتبات، أطر العمل، أو حتى المكونات الكاملة) بين التطبيقات المترجمة بشكل منفصل. هذا يعني أنه يمكنك امتلاك تطبيقات متعددة ومتميزة (يشار إليها غالبًا بـ 'remotes' أو 'consumers') يمكنها تحميل الكود من تطبيق 'container' أو 'host'، والعكس صحيح.

الفوائد الأساسية لتجميع الوحدات تشمل:

• مشاركة الكود: التخلص من الكود المكرر عبر تطبيقات متعددة، مما يقلل من أحجام الحزم الإجمالية ويحسن أوقات التحميل.
• النشر المستقل: يمكن للفرق تطوير ونشر أجزاء مختلفة من تطبيق كبير بشكل مستقل، مما يعزز المرونة ويسرع دورات الإصدار.
• الحياد التكنولوجي: على الرغم من استخدامه بشكل أساسي مع Webpack، إلا أنه يسهل المشاركة عبر أدوات بناء أو أطر عمل مختلفة إلى حد ما، مما يعزز المرونة.
• التكامل في وقت التشغيل: يمكن تجميع التطبيقات في وقت التشغيل، مما يسمح بالتحديثات الديناميكية والهياكل التطبيقية المرنة.

المشكلة: التبعيات المكررة في الواجهات الأمامية المصغرة

تخيل سيناريو حيث لديك عدة واجهات أمامية مصغرة تعتمد جميعها على نفس الإصدار من مكتبة واجهة مستخدم شائعة مثل React، أو مكتبة لإدارة الحالة مثل Redux. بدون آلية للمشاركة، ستقوم كل واجهة أمامية مصغرة بتضمين نسختها الخاصة من هذه التبعيات. وهذا يؤدي إلى:

• تضخم أحجام الحزم: كل تطبيق يكرر المكتبات المشتركة بشكل غير ضروري، مما يؤدي إلى أحجام تنزيل أكبر للمستخدمين.
• زيادة استهلاك الذاكرة: يمكن أن تستهلك مثيلات متعددة من نفس المكتبة المحملة في المتصفح المزيد من الذاكرة.
• سلوك غير متسق: يمكن أن تؤدي الإصدارات المختلفة من المكتبات المشتركة عبر التطبيقات إلى أخطاء دقيقة ومشاكل توافق.
• إهدار موارد الشبكة: قد يقوم المستخدمون بتنزيل نفس المكتبة عدة مرات إذا تنقلوا بين واجهات أمامية مصغرة مختلفة.

هنا يأتي دور النطاق المشترك في تجميع الوحدات، مقدمًا حلاً أنيقًا لهذه التحديات.

فهم النطاق المشترك في تجميع الوحدات

النطاق المشترك، الذي يتم تكوينه غالبًا عبر خيار shared ضمن ملحق Module Federation، هو الآلية التي تمكن تطبيقات متعددة منشورة بشكل مستقل من مشاركة التبعيات. عند تكوينه، يضمن تجميع الوحدات تحميل نسخة واحدة فقط من التبعية المحددة وإتاحتها لجميع التطبيقات التي تتطلبها.

في جوهره، يعمل النطاق المشترك عن طريق إنشاء سجل عالمي أو حاوية للوحدات المشتركة. عندما يطلب تطبيق ما تبعية مشتركة، يقوم تجميع الوحدات بفحص هذا السجل. إذا كانت التبعية موجودة بالفعل (أي، تم تحميلها بواسطة تطبيق آخر أو المضيف)، فإنه يستخدم تلك النسخة الموجودة. وإلا، فإنه يقوم بتحميل التبعية وتسجيلها في النطاق المشترك للاستخدام المستقبلي.

يبدو التكوين عادةً كما يلي:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ... other webpack configurations
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        'app1': 'app1@http://localhost:3001/remoteEntry.js',
        'app2': 'app2@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

خيارات التكوين الرئيسية للتبعيات المشتركة:

• singleton: true: ربما يكون هذا هو الخيار الأكثر أهمية. عند تعيينه إلى true، فإنه يضمن تحميل نسخة واحدة فقط من التبعية المشتركة عبر جميع التطبيقات المستهلكة. إذا حاولت تطبيقات متعددة تحميل نفس التبعية المفردة، فسيوفر لها تجميع الوحدات نفس النسخة.
• eager: true: بشكل افتراضي، يتم تحميل التبعيات المشتركة بشكل كسول (lazily)، مما يعني أنه يتم جلبها فقط عند استيرادها أو استخدامها بشكل صريح. يؤدي تعيين eager: true إلى إجبار التبعية على التحميل بمجرد بدء تشغيل التطبيق، حتى لو لم يتم استخدامها على الفور. يمكن أن يكون هذا مفيدًا للمكتبات الحيوية مثل أطر العمل لضمان توفرها منذ البداية.
• requiredVersion: '...': يحدد هذا الخيار الإصدار المطلوب من التبعية المشتركة. سيحاول تجميع الوحدات مطابقة الإصدار المطلوب. إذا كانت تطبيقات متعددة تتطلب إصدارات مختلفة، فإن لدى تجميع الوحدات آليات للتعامل مع ذلك (سيتم مناقشته لاحقًا).
• version: '...': يمكنك تعيين إصدار التبعية الذي سيتم نشره في النطاق المشترك بشكل صريح.
• import: false: يخبر هذا الإعداد تجميع الوحدات بعدم تضمين التبعية المشتركة تلقائيًا. بدلاً من ذلك، يتوقع أن يتم توفيرها خارجيًا (وهو السلوك الافتراضي عند المشاركة).
• packageDir: '...': يحدد دليل الحزمة لحل التبعية المشتركة منه، وهو مفيد في المستودعات الأحادية (monorepos).

كيف يُمكّن النطاق المشترك من مشاركة التبعيات

دعنا نحلل العملية بمثال عملي. تخيل أن لدينا تطبيق 'حاوية' رئيسي وتطبيقين 'عن بعد'، `app1` و `app2`. تعتمد التطبيقات الثلاثة جميعها على `react` و `react-dom` الإصدار 18.

السيناريو 1: تطبيق الحاوية يشارك التبعيات

في هذا الإعداد الشائع، يحدد تطبيق الحاوية التبعيات المشتركة. يكشف ملف `remoteEntry.js`، الذي تم إنشاؤه بواسطة تجميع الوحدات، عن هذه الوحدات المشتركة.

تكوين Webpack الخاص بالحاوية (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

الآن، سيستهلك `app1` و `app2` هذه التبعيات المشتركة.

تكوين Webpack الخاص بـ `app1` (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

تكوين Webpack الخاص بـ `app2` (`app2/webpack.config.js`):

سيكون تكوين `app2` مشابهًا لـ `app1`، مع الإعلان أيضًا عن `react` و `react-dom` كمشتركين بنفس متطلبات الإصدار.

كيف يعمل في وقت التشغيل:

1. يتم تحميل تطبيق الحاوية أولاً، مما يجعل مثيلات `react` و `react-dom` المشتركة متاحة في نطاق تجميع الوحدات الخاص به.
2. عندما يتم تحميل `app1`، فإنه يطلب `react` و `react-dom`. يرى تجميع الوحدات في `app1` أنها محددة كمشتركة و `singleton: true`. يفحص النطاق العالمي بحثًا عن المثيلات الموجودة. إذا كان الحاوية قد حملها بالفعل، فإن `app1` يعيد استخدام تلك المثيلات.
3. وبالمثل، عندما يتم تحميل `app2`، فإنه يعيد استخدام نفس مثيلات `react` و `react-dom`.

ينتج عن هذا تحميل نسخة واحدة فقط من `react` و `react-dom` في المتصفح، مما يقلل بشكل كبير من حجم التنزيل الإجمالي.

السيناريو 2: مشاركة التبعيات بين التطبيقات البعيدة

يسمح تجميع الوحدات أيضًا للتطبيقات البعيدة بمشاركة التبعيات فيما بينها. إذا كان `app1` و `app2` يستخدمان مكتبة *لا* يشاركها الحاوية، فلا يزال بإمكانهما مشاركتها إذا أعلن كلاهما عنها كمشتركة في تكويناتهما الخاصة.

مثال: لنفترض أن `app1` و `app2` يستخدمان مكتبة الأدوات المساعدة `lodash`.

تكوين Webpack الخاص بـ `app1` (إضافة lodash):

            
// ... within ModuleFederationPlugin for app1
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

تكوين Webpack الخاص بـ `app2` (إضافة lodash):

            
// ... within ModuleFederationPlugin for app2
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

في هذه الحالة، حتى لو لم يشارك الحاوية `lodash` بشكل صريح، فإن `app1` و `app2` سيتمكنان من مشاركة نسخة واحدة من `lodash` بينهما، شريطة أن يتم تحميلهما في نفس سياق المتصفح.

التعامل مع عدم تطابق الإصدارات

أحد أكثر التحديات شيوعًا في مشاركة التبعيات هو توافق الإصدارات. ماذا يحدث عندما يتطلب `app1` `react` v18.1.0 ويتطلب `app2` `react` v18.2.0؟ يوفر تجميع الوحدات استراتيجيات قوية لإدارة هذه السيناريوهات.

1. مطابقة الإصدار الصارمة (السلوك الافتراضي لـ `requiredVersion`)

عند تحديد إصدار دقيق (مثل '18.1.0') أو نطاق صارم (مثل '^18.1.0')، سيفرض تجميع الوحدات ذلك. إذا حاول تطبيق تحميل تبعية مشتركة بإصدار لا يلبي متطلبات تطبيق آخر يستخدمها بالفعل، فقد يؤدي ذلك إلى أخطاء.

2. نطاقات الإصدار والبدائل

يدعم خيار requiredVersion نطاقات الإصدار الدلالي (SemVer). على سبيل المثال، '^18.0.0' يعني أي إصدار من 18.0.0 حتى (ولكن لا يشمل) 19.0.0. إذا كانت تطبيقات متعددة تتطلب إصدارات ضمن هذا النطاق، فسيستخدم تجميع الوحدات عادةً أعلى إصدار متوافق يلبي جميع المتطلبات.

تأمل هذا:

• الحاوية: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

إذا تم تحميل الحاوية أولاً، فإنه يؤسس `react` v18.0.0 (أو أي إصدار يقوم بتجميعه بالفعل). عندما يطلب `app1` `react` مع `^18.1.0`، فقد يفشل إذا كان إصدار الحاوية أقل من 18.1.0. ومع ذلك، إذا تم تحميل `app1` أولاً وقدم `react` v18.1.0، ثم طلب `app2` `react` مع `^18.2.0`، فسيحاول تجميع الوحدات تلبية متطلبات `app2`. إذا كانت نسخة `react` v18.1.0 محملة بالفعل، فقد يلقي خطأ لأن v18.1.0 لا يفي بمتطلبات `^18.2.0`.

للتخفيف من هذا، من الأفضل تحديد التبعيات المشتركة مع أوسع نطاق إصدار مقبول، عادةً في تطبيق الحاوية. على سبيل المثال، استخدام '^18.0.0' يسمح بالمرونة. إذا كان لدى تطبيق بعيد معين تبعية صارمة على إصدار تصحيح أحدث، فيجب تكوينه لتوفير هذا الإصدار بشكل صريح.

3. استخدام `shareKey` و `shareScope`

يسمح تجميع الوحدات أيضًا بالتحكم في المفتاح الذي تتم مشاركة الوحدة تحته والنطاق الذي توجد فيه. يمكن أن يكون هذا مفيدًا للسيناريوهات المتقدمة، مثل مشاركة إصدارات مختلفة من نفس المكتبة تحت مفاتيح مختلفة.

4. خيار `strictVersion`

عند تمكين strictVersion (وهو الإعداد الافتراضي لـ requiredVersion)، يلقي تجميع الوحدات خطأ إذا لم يمكن تلبية التبعية. يمكن أن يسمح تعيين strictVersion: false بمعالجة أكثر تساهلاً للإصدارات، حيث قد يحاول تجميع الوحدات استخدام إصدار أقدم إذا لم يكن إصدار أحدث متاحًا، ولكن هذا يمكن أن يؤدي إلى أخطاء في وقت التشغيل.

أفضل الممارسات لاستخدام النطاق المشترك

للاستفادة بفعالية من النطاق المشترك في تجميع الوحدات وتجنب المزالق الشائعة، ضع في اعتبارك هذه الممارسات الأفضل:

1. مركزية التبعيات المشتركة: عيّن تطبيقًا أساسيًا (غالبًا الحاوية أو تطبيق مكتبة مشتركة مخصص) ليكون مصدر الحقيقة للتبعيات الشائعة والمستقرة مثل أطر العمل (React, Vue, Angular)، ومكتبات مكونات واجهة المستخدم، ومكتبات إدارة الحالة.
2. تحديد نطاقات إصدار واسعة: استخدم نطاقات SemVer (مثل '^18.0.0') للتبعيات المشتركة في التطبيق المشارك الأساسي. هذا يسمح للتطبيقات الأخرى باستخدام إصدارات متوافقة دون فرض تحديثات صارمة عبر النظام البيئي بأكمله.
3. توثيق التبعيات المشتركة بوضوح: حافظ على وثائق واضحة حول التبعيات التي تتم مشاركتها وإصداراتها والتطبيقات المسؤولة عن مشاركتها. هذا يساعد الفرق على فهم مخطط التبعية.
4. مراقبة أحجام الحزم: قم بتحليل أحجام حزم تطبيقاتك بانتظام. يجب أن يؤدي النطاق المشترك في تجميع الوحدات إلى تقليل حجم الأجزاء المحملة ديناميكيًا حيث يتم استخراج التبعيات الشائعة.
5. إدارة التبعيات غير الحتمية: كن حذرًا مع التبعيات التي يتم تحديثها بشكل متكرر أو التي تحتوي على واجهات برمجة تطبيقات غير مستقرة. قد تتطلب مشاركة مثل هذه التبعيات إدارة إصدارات واختبارات أكثر دقة.
6. استخدام `eager: true` بحكمة: بينما يضمن `eager: true` تحميل التبعية مبكرًا، يمكن أن يؤدي الإفراط في استخدامه إلى زيادة أوقات التحميل الأولية. استخدمه للمكتبات الحيوية التي لا غنى عنها لبدء تشغيل التطبيق.
7. الاختبار أمر بالغ الأهمية: اختبر تكامل واجهاتك الأمامية المصغرة بدقة. تأكد من تحميل التبعيات المشتركة بشكل صحيح وأن تعارضات الإصدارات يتم التعامل معها بأمان. الاختبار الآلي، بما في ذلك اختبارات التكامل والاختبارات الشاملة (end-to-end)، أمر حيوي.
8. فكر في استخدام المستودعات الأحادية (Monorepos) للتبسيط: بالنسبة للفرق التي تبدأ بتجميع الوحدات، يمكن أن تبسط إدارة التبعيات المشتركة داخل مستودع أحادي (باستخدام أدوات مثل Lerna أو Yarn Workspaces) الإعداد وتضمن الاتساق. خيار `packageDir` مفيد بشكل خاص هنا.
9. التعامل مع الحالات الخاصة باستخدام `shareKey` و `shareScope`: إذا واجهت سيناريوهات إصدارات معقدة أو احتجت إلى كشف إصدارات مختلفة من نفس المكتبة، فاستكشف خيارات `shareKey` و `shareScope` لمزيد من التحكم الدقيق.
10. اعتبارات أمنية: تأكد من جلب التبعيات المشتركة من مصادر موثوقة. قم بتنفيذ أفضل الممارسات الأمنية لخط أنابيب البناء وعملية النشر الخاصة بك.

التأثير العالمي والاعتبارات

بالنسبة لفرق التطوير العالمية، يقدم تجميع الوحدات ونطاقه المشترك مزايا كبيرة:

• الاتساق عبر المناطق: يضمن أن جميع المستخدمين، بغض النظر عن موقعهم الجغرافي، يجربون التطبيق بنفس التبعيات الأساسية، مما يقلل من التناقضات الإقليمية.
• دورات تكرار أسرع: يمكن للفرق في مناطق زمنية مختلفة العمل على ميزات مستقلة أو واجهات أمامية مصغرة دون القلق المستمر بشأن تكرار المكتبات المشتركة أو التدخل في إصدارات التبعيات الخاصة بالآخرين.
• محسّن للشبكات المتنوعة: يعد تقليل حجم التنزيل الإجمالي من خلال التبعيات المشتركة مفيدًا بشكل خاص للمستخدمين على اتصالات الإنترنت البطيئة أو المحدودة، والتي تنتشر في أجزاء كثيرة من العالم.
• تبسيط عملية الانضمام: يمكن للمطورين الجدد الذين ينضمون إلى مشروع كبير فهم بنية التطبيق وإدارة التبعيات بسهولة أكبر عندما تكون المكتبات المشتركة محددة ومشاركة بوضوح.

ومع ذلك، يجب على الفرق العالمية أيضًا أن تكون على دراية بـ:

• استراتيجيات CDN: إذا كانت التبعيات المشتركة مستضافة على CDN، فتأكد من أن CDN لديها وصول عالمي جيد وزمن انتقال منخفض لجميع المناطق المستهدفة.
• الدعم دون اتصال بالإنترنت: بالنسبة للتطبيقات التي تتطلب قدرات دون اتصال بالإنترنت، تصبح إدارة التبعيات المشتركة وتخزينها المؤقت أكثر تعقيدًا.
• الامتثال التنظيمي: تأكد من أن مشاركة المكتبات تتوافق مع أي تراخيص برمجيات ذات صلة أو لوائح خصوصية البيانات في ولايات قضائية مختلفة.

الأخطاء الشائعة وكيفية تجنبها

1. تكوين `singleton` بشكل غير صحيح

المشكلة: نسيان تعيين singleton: true للمكتبات التي يجب أن يكون لها نسخة واحدة فقط.

الحل: قم دائمًا بتعيين singleton: true لأطر العمل والمكتبات والأدوات التي تنوي مشاركتها بشكل فريد عبر تطبيقاتك.

2. متطلبات إصدار غير متسقة

المشكلة: تطبيقات مختلفة تحدد نطاقات إصدار مختلفة تمامًا وغير متوافقة لنفس التبعية المشتركة.

الحل: قم بتوحيد متطلبات الإصدار، خاصة في تطبيق الحاوية. استخدم نطاقات SemVer واسعة ووثق أي استثناءات.

3. الإفراط في مشاركة المكتبات غير الأساسية

المشكلة: محاولة مشاركة كل مكتبة أدوات صغيرة، مما يؤدي إلى تكوين معقد وصراعات محتملة.

الحل: ركز على مشاركة التبعيات الكبيرة والشائعة والمستقرة. قد يكون من الأفضل تجميع الأدوات الصغيرة ونادرة الاستخدام محليًا لتجنب التعقيد.

4. عدم التعامل مع ملف `remoteEntry.js` بشكل صحيح

المشكلة: عدم إمكانية الوصول إلى ملف `remoteEntry.js` أو عدم تقديمه بشكل صحيح للتطبيقات المستهلكة.

الحل: تأكد من أن استراتيجية استضافة الإدخالات البعيدة قوية وأن عناوين URL المحددة في تكوين `remotes` دقيقة ويمكن الوصول إليها.

5. تجاهل تداعيات `eager: true`

المشكلة: تعيين eager: true على عدد كبير جدًا من التبعيات، مما يؤدي إلى بطء وقت التحميل الأولي.

الحل: استخدم eager: true فقط للتبعيات التي تعتبر حيوية للغاية للعرض الأولي أو الوظائف الأساسية لتطبيقاتك.

الخاتمة

يعد النطاق المشترك في تجميع وحدات JavaScript أداة قوية لبناء تطبيقات ويب حديثة وقابلة للتطوير، خاصة ضمن بنية الواجهات الأمامية المصغرة. من خلال تمكين المشاركة الفعالة للتبعيات، فإنه يعالج مشاكل تكرار الكود والتضخم وعدم الاتساق، مما يؤدي إلى تحسين الأداء والصيانة. إن فهم وتكوين خيار shared بشكل صحيح، خاصة خصائص singleton و requiredVersion، هو مفتاح إطلاق هذه الفوائد.

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

احتضن قوة النطاق المشترك، ومهد الطريق لتطوير ويب أكثر كفاءة وتعاونًا عبر مؤسستك.