बंडलों में नकली पैकेज से छुटकारा

कई वेबपैक पैकेज हैं जो बंडल में डुप्लिकेट पाते हैं, उनमें से सबसे लोकप्रिय डुप्लिकेट-पैकेज-चेकर-वेबपैक-प्लगइन है , लेकिन इसके लिए प्रोजेक्ट को फिर से तैयार करने की आवश्यकता होती है, और चूंकि पैकेज के इष्टतम संस्करण के चयन को स्वचालित करने का काम था, इसलिए इसका अपना वैकल्पिक समाधान निकला।

खैर, या मेरी कहानी कि यह कैसे 15% से कुछ ही सेकंड में बंडल को कम करने के लिए निकला।

जैसा कि कई बड़ी कंपनियों में एक विशाल कोड बेस है, बहुत सारे सामान्य तर्क हैं, जिसके परिणामस्वरूप हम अपने npm रिपॉजिटरी में प्रकाशित आम घटकों का उपयोग करते हैं। वे सामान्य घटकों के प्रत्येक अधिष्ठापन या अद्यतन से पहले क्रमशः लर्न के माध्यम से प्रकाशित होते हैं, सवाल उठता है कि किस संस्करण को स्थापित किया जाए। लर्नना सभी घटकों को ओवरराइड करता है जो प्रकाशित घटक का उपयोग करता है (यदि संस्करण पहले अंतिम था)। तदनुसार, हमेशा कई घटकों के संस्करण होते हैं जो एक-दूसरे के लिए बेहतर अनुकूल होते हैं, क्योंकि वे निर्भरता के साथ प्रतिस्पर्धा नहीं करते हैं।

इस तरह से ओपन सोर्स प्रोजेक्ट्स से, यहाँ उनका लर्न कॉन्फ़िगरेशन है ।

डुप्लिकेट निर्भरताएँ तब कैसे दिखाई देती हैं? और उन्हें कैसे खत्म किया जाए?

मान लीजिए कि आपके पास निम्नलिखित 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 कहां @nivo/core :

 npm list @nivo/core 

हम @nivo/core की 4 प्रतियां ( 0.54.0 की 3 प्रतियां और 1 - 0.53.0 ) देखते हैं। लेकिन अगर हम @nivo/core के मामूली संस्करण को 0.54.0 , तो डुप्लिकेट को समाप्त कर दिया जाएगा।

वर्तमान उदाहरण सरल है, लेकिन व्यवहार में, प्रत्येक पैकेज में अधिक निर्भरताएं हैं, और आपको अभी भी आगे की निर्भरता पर विचार करने की आवश्यकता है, जिससे कार्य की जटिलता बढ़ जाती है।

और एक बार फिर बंडल के विशाल आकार को देखकर, मैं मैन्युअल रूप से डुप्लिकेट पैकेटों को हटाकर थक गया था।

सामान्य तौर पर, पैकेजों को तुरंत नवीनतम संस्करण में अपग्रेड करने का अधिकार है, लेकिन प्रमुख संस्करणों को बदलने के लिए हमेशा की तरह समय नहीं है, और उपयुक्त पैकेज का आंख मूंदकर चयन करना लंबा और कठिन है। आखिरकार, आपको package.json में निर्भरता संस्करण को अपडेट करने की आवश्यकता है, नई निर्भरताएं स्थापित करें, और फिर जांचें कि क्या बिल्ड में डुप्लिकेट गायब हो गए हैं, यदि नहीं, तो दोहराएं, लंबे समय तक, औसतन, प्रति चलना 3-4 मिनट।

यह सब नीरस है और ध्यान देने की आवश्यकता है, इसलिए मैंने स्वचालित करने का फैसला किया।

मैं निर्भरता को पुनर्स्थापित किए बिना डुप्लिकेट जानना चाहूंगा, और परियोजना का पुनर्निर्माण कर सकता हूं, आदर्श रूप से क्ली एप्लिकेशन जो 10 सेकंड में अनुकूलन विकल्प प्रदर्शित करता है और परियोजना में सभी मौजूदा डुप्लिकेट।

ले के उन्मूलन को कई उप-प्रकारों में विभाजित किया जा सकता है, हम उन्हें क्रम में विचार करेंगे।

पहला काम। आपको भविष्य के बंडल निर्भरता के पेड़ को केवल पैकेज के द्वारा मॉडल करने की आवश्यकता है। आगजनी, मानक कटौती को देखते हुए, जल्दी से, 100 मीटर से अधिक नहीं।

मैंने विभिन्न संस्करणों की तुलना करने के लिए पैकेज और सेवर की जानकारी प्राप्त करने के लिए पैकेज- जसन का उपयोग करने का निर्णय लिया।

परिणाम एक npm पैकेज निर्भरता-ट्री-बिल्डर था , चालाकी से बंडल डिपेंडेंसी ट्री को package.json द्वारा ही मॉडलिंग किया गया।

एक अलग घटक के लिए आवंटित किया गया है, क्योंकि हो सकता है कि कोई व्यक्ति पैकेज.जसन के साथ दहन कार्यों में इसका पुन: उपयोग करेगा।

दूसरा कार्य। एक संयोजन कार्य, निर्भरता बदलने के लिए विकल्पों की एक कुशल गणना, और पेड़ों के लिए कई विकल्पों की तुलना, और निश्चित रूप से, इष्टतम एक की पसंद।

किसी तरह परिणामी पेड़ों की तुलनात्मक रूप से तुलना करना आवश्यक था, और हमें एन्ट्रापी के विचार को उधार लेना पड़ा, विकार के मात्रात्मक माप के रूप में, डुप्लिकेट प्रतियों का योग लिया (ऊपर के उदाहरण से यह 3 है)।

पैकेज वेट्स को खाते में (KB में) लेना बहुत अच्छा होगा, लेकिन दुर्भाग्य से मुझे ऐसा पैकेज नहीं मिला, जो वज़न के साथ जल्दी काम करे, और जो प्रति पैकेज लगभग आधे मिनट के लिए काम करते हैं, उदाहरण के लिए पैकेज-आकार । चूंकि वे निम्नलिखित सिद्धांत के अनुसार काम करते हैं: एकल निर्भरता के साथ एक परियोजना बनाएं, निर्भरताएं स्थापित करें, जिसके बाद फ़ोल्डर का कुल वजन मापा जाता है। नतीजतन, मैं एक और कसौटी के साथ नहीं आया, डुप्लिकेट प्रतियों की संख्या के रूप में।

यह समझने के लिए कि किस पैकेज को बदलने की आवश्यकता है, डुप्लिकेट के कारणों को, विशेष रूप से स्रोत और प्रभाव को माना जाता है। एन्युमरेशन डुप्लिकेट प्रभावों को यथासंभव समाप्त करता है, और चूंकि प्रभाव समाप्त हो जाते हैं, इसलिए बाद में भी डुप्लिकेट होते हैं।

नतीजतन , हमें एक छोटा सीएलआई ओस्टैप एप्लिकेशन मिला जो बंडल में डुप्लिकेट इंस्टेंस की संख्या को कम करने के लिए इष्टतम संस्करणों की सिफारिश करता है।

यह सिर्फ आपके प्रोजेक्ट के पैकेज.जॉन की ओर इशारा करके शुरू होता है।

 ostap ./package.json 

आप पैकेज में केवल संस्करणों को बदलकर परियोजना के पुनर्निर्माण के बिना भविष्य में लगने वाले सभी कार्यों को जल्दी से देखने के लिए भी इसका उपयोग कर सकते हैं।

 ostap ./package.json -s 

नतीजतन, मेरी परियोजना में बंडलों का कुल वजन 15% कम हो गया।

रिपॉजिटरी में एक त्वरित शुरुआत अनुभाग है।

यदि आप मार्ग-विभाजन का उपयोग करते हैं, तो ऐसा लग सकता है कि कुछ बंडल वजन में बढ़ गए हैं, लेकिन घटकों के वितरण में बदलाव हो सकता है। यही है, प्रत्येक पृष्ठ पर निर्भरता की प्रतियों के बजाय, एकमात्र संस्करण सभी पृष्ठों के लिए एक सामान्य बंडल में बदल गया है, इसलिए आपको सभी पृष्ठों के लिए बंडलों के कुल वजन का मूल्यांकन करने की आवश्यकता है।

आशा है कि लेख उपयोगी था। और कोई समय की जानकारी बचाएगा। आपका धन्यवाद

फिर से सुविधा के लिए संदर्भ:

• पैकेज पैकेज द्वारा पैकेज बंडल निर्भरता मॉडलिंग मॉडलिंग। json
  GitHub ;
• एक बंडल में डुप्लिकेट को समाप्त करने के लिए निर्भरता अनुकूलक
  GitHub ।

यदि आपके पास दिलचस्प विचार हैं, तो जीथब पर जारी करने के लिए लिखें, हम इस पर चर्चा करेंगे।