التخلص من الحزم المكررة في الحزم

هناك العديد من حزم webpack التي تجد التكرارات في الحزمة ، والأكثر شيوعًا منها هو duplicate-package-checker-webpack-plugin ، لكنه يتطلب إعادة تجميع المشروع ، وبما أنه كانت هناك مهمة لأتمتة اختيار الإصدار الأمثل من الحزم ، فقد تحول إلى حل بديل خاص به.

حسنًا ، أو قصتي هي كيف تحولت إلى خفض الحزمة بنسبة 15 ٪ ، في بضع ثوان.

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

من المشاريع مفتوحة المصدر في هذا السبيل ، هنا هو التكوين lerna بهم .

كيف تظهر التبعيات المكررة بعد ذلك؟ وكيف تقضي عليهم؟

افترض أن لديك مشروع بسيط مع package.json التالية: package.json :

 { "name": "demo-project", "version": "1.0.0", "dependencies": { "@nivo/bar": "0.54.0", "@nivo/core": "0.53.0", "@nivo/pie": "0.54.0", "@nivo/stream": "0.54.0" } } 

لنرى أين @nivo/core :

 npm list @nivo/core 

نرى 4 نسخ من @nivo/core (3 نسخ من 0.54.0 و 1 - 0.53.0 ). ولكن إذا قمنا بتغيير الإصدار الثانوي من @nivo/core إلى 0.54.0 ، فسيتم القضاء على التكرارات.

المثال الحالي بسيط ، ولكن في الممارسة العملية ، بالطبع ، تحتوي كل حزمة على مزيد من التبعيات ، ولا تزال بحاجة إلى النظر في التبعيات بشكل أكبر ، مما يزيد من تعقيد المهمة.

ومرة أخرى أرى الحجم الكبير للحزمة ، لقد سئمت من إزالة الحزم المكررة يدويًا.

بشكل عام ، من الصواب ترقية الحزم فورًا إلى أحدث إصدار ، ولكن ليس هناك وقت ، كما هو الحال دائمًا ، لتغيير الإصدارات الرئيسية ، ومن الصعب تحديد الحزمة المناسبة منذ فترة طويلة وصعبة. بعد كل شيء ، تحتاج إلى تحديث إصدار التبعية في package.json ، وتثبيت تبعيات جديدة ، ثم تحقق مما إذا كانت التكرارات قد اختفت في الإنشاء ، إن لم يكن ، كرر ، لفترة طويلة ، في المتوسط ​​، 3-4 دقائق لكل تكرار.

كل هذا رتيب ويتطلب الاهتمام ، لذلك قررت أن أتمتة.

أرغب في معرفة التكرارات دون إعادة تثبيت التبعيات وإعادة إنشاء المشروع ، وهو تطبيق cli مثالي يعرض خيارات التحسين في 10 ثوانٍ وجميع التكرارات الموجودة في المشروع.

القضاء على يأخذ يمكن تقسيمها إلى عدة مهام فرعية ، وسوف ننظر فيها بالترتيب.

المهمة الأولى. يجب أن تصمم شجرة تبعية الحزمة المستقبلية فقط من خلال package.json ، بالنظر إلى dedupe القياسي ، بسرعة ، في أكثر من 100ms.

قررت استخدام package-json للحصول على معلومات عن الحزم و semver لمقارنة الإصدارات المختلفة.

وكانت النتيجة بناء التبعيات في حزمة npm -tree-builder ، حيث قام بتصميم بذكاء شجرة تبعية الحزمة فقط بواسطة package.json.

خصصت لعنصر منفصل ، لأنه ربما يعيد استخدامه شخص ما في المهام التوافقية مع package.json.

المهمة الثانية. مهمة توافقية ، تعداد فعال للخيارات لتغيير التبعيات ، ومقارنة بين عدة خيارات للأشجار ، وبالطبع اختيار الخيار الأمثل.

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

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

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

نتيجةً لذلك ، حصلنا على تطبيق cli ostap صغير يوصي بالإصدارات المثلى لتقليل عدد النسخ المكررة في الحزمة.

يبدأ فقط بالإشارة إلى package.json لمشروعك.

 ostap ./package.json 

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

 ostap ./package.json -s 

ونتيجة لذلك ، انخفض إجمالي وزن الحزم في مشروعي بنسبة 15٪.

يحتوي المستودع على قسم بداية سريعة.

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

آمل أن المقالة كانت مفيدة. وشخص سيوفر معلومات الوقت. شكرا لك

مراجع للراحة مرة أخرى:

• حزمة نمذجة شجرة التبعية حزمة بواسطة package.json
  جيثب .
• مُحسِّن التبعية للتخلص من التكرارات في حزمة
  جيثب .

إذا كانت لديك أفكار مثيرة للاهتمام ، فاكتب للإصدار على جيثب ، سنناقشها.