एनपीएम फीचर्स और git में नोड_मॉड्यूल्स को स्टोर करना

एक परियोजना में निर्भरता का प्रबंधन करने के लिए, कई अन्य प्लेटफार्मों की तरह नोड.जेएस, अपना स्वयं का पैकेज प्रबंधक, एनपीएम प्रदान करता है। और इस तथ्य के बावजूद कि यह समान दिखता है, उदाहरण के लिए, रूबी रत्न के लिए, और समान कार्य करने के लिए लगता है, npm में कुछ विशेषताएं हैं जिन्हें नोड.जेएस पर अनुप्रयोग विकसित करते समय विचार किया जाना चाहिए। इन सुविधाओं में से एक है जिस तरह से नोड_मॉडल्स निर्देशिका परियोजना में संग्रहीत की जाती है। कई, अन्य प्रणालियों के साथ समानता से, केवल पैकेज को छोड़ देते हैं। परियोजना में मॉड्यूल के निश्चित संस्करणों के साथ, और नोड_मॉड्यूल्स को toignignore में जोड़ा जाता है। यह रणनीति हमेशा सच नहीं होती है, अगर हम npmjs.org पर अक्सर पूछे जाने वाले प्रश्नों को देखते हैं , तो हम निम्नलिखित देखेंगे:

प्रश्न: क्या यह git में नोड_मॉड्यूल्स के भंडारण के लायक है?
ए: मिकाइल रोजर्स ने इस सवाल का जवाब दिया:
http://www.mikealrogers.com/posts/nodemodules-in-git.html
tl; डॉ

• उन परियोजनाओं के लिए git_modules को संग्रहीत करें, जिन्हें आपको वेबसाइटों और एप्लिकेशन जैसे परिनियोजित करने की आवश्यकता है।
• पुस्तकालयों और पुन: प्रयोज्य मॉड्यूल के लिए नोड_मॉड्यूल को .gitignore में जोड़ें।
• देव माहौल में निर्भरता का प्रबंधन करने के लिए npm का उपयोग करें, लेकिन तैनाती के लिए उपयोग की जाने वाली लिपियों में नहीं।

कट के तहत मिकाइल रोजर्स के एक लेख का अनुवाद है, जिसमें विस्तार से वर्णन किया गया है कि यह असामान्य दृष्टिकोण क्या है।

नोड.जेएस की दुनिया में पुनर्विचार के लिए आवश्यक मुद्दों में से एक आवेदन निर्भरता के प्रबंधन का मुद्दा है।

नोड 0.4.0 के साथ आए बड़े परिवर्तनों में से एक नोड_मॉड्यूल्स के लिए समर्थन था। इस परिवर्तन के गंभीर परिणाम हुए हैं। इसने विश्व स्तर पर स्थापित मॉड्यूल पर स्थानीय निर्देशिका में स्थानीय मॉड्यूल की प्राथमिकता को उठाया। उसी समय, npm ने वैश्विक से स्थानीय के लिए डिफ़ॉल्ट सेटिंग बदल दी और हमने स्थानीय मॉड्यूल में लगभग एकमत संक्रमण देखा।

वैश्विक से स्थानीय मॉड्यूल में संक्रमण वह है जो पिछली पीढ़ियों के प्लेटफार्मों से नोड को अलग करता है। रूबी और पायथन इस क्षेत्र में पूरी तरह से विफल रहे, और यह तथ्य कि पूरे प्लेटफॉर्म (वर्चुअन, आरवीएम) के लिए एक अलग सैंडबॉक्स में विकास और तैनाती मानक अभ्यास बन गया है, विफलता की मान्यता है।

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

अब हम पहले से ही स्थानीय मॉड्यूल्स के आदी हैं, इसकी आदत पड़ गई है, इसके बावजूद कि शुरुआती स्तर पर कुछ परेशानियों का सामना करना पड़ रहा है। और फिर भी हम उन पुरानी आदतों को पकड़ते हैं जो हमने पुराने वैश्विक दिनों से छोड़ी हैं।

जब हम वैश्विक प्रतिष्ठानों के साथ काम कर रहे थे, और विशेष रूप से नाम संघर्षों को हल करने के लिए स्थानीय लोगों पर वैश्विक मॉड्यूल के लाभ के साथ, एक संस्करण नियंत्रण प्रणाली में निर्भरता का भंडारण करना एक बहुत बुरा विचार था। यह मुख्य रूप से खराब है क्योंकि यह एक खुला झूठ है। एक निर्भरता कोड की उपस्थिति का मतलब यह नहीं है कि इसका उपयोग किया जाएगा यदि समान मॉड्यूल वैश्विक रूप से स्थापित किया गया है। हमने यह सुनिश्चित करने के लिए भारी तैनाती उपकरण विकसित किए हैं कि जब कोड एक ही स्थान पर तैनात किया जाता है, और एक हफ्ते बाद उसी कोड को किसी अन्य स्थान पर तैनात किया जाता है, तो दोनों प्रतिष्ठानों को निर्भरता का एक ही सेट प्राप्त होगा। ये सभी उपकरण अनाड़ी हैं, क्योंकि समस्या स्वयं अनाड़ी है।

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

हर किसी ने मुझे यह बताया कि मैं एक बेवकूफ था, और फिर, कुछ हफ़्ते के बाद, उन्होंने कहा कि मैं सही था और यह कि g_ में नोड_मॉड्यूल रखना तैनाती और विकास दोनों के लिए एक आशीर्वाद था। यह उद्देश्यपूर्ण रूप से बेहतर है, लेकिन यहां कुछ प्रश्न / शिकायतें हैं:

मैं यह सुनिश्चित करने के लिए केवल संस्करण क्यों नहीं करता कि सभी प्रतिष्ठानों को समान निर्भरता मिले?

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

हम पुस्तकालय रखरखावकर्ताओं को उनकी निर्भरता के संस्करणों को ठीक करने के लिए प्रोत्साहित क्यों नहीं करते हैं?

आज तक, एनपीएम रजिस्ट्री में लगभग 5,500 पैकेज हैं ( अनुवादक का नोट: दिसंबर 2011 तक के आंकड़े, अब उनमें से लगभग 34,000 हैं। ) पिछले महीने में, 600 से अधिक नए पैकेज जोड़े गए हैं और 5,000 से अधिक अपडेट किए गए हैं। कुछ पैकेजों के लिए, सप्ताह के दौरान कई अपडेट जारी किए गए थे। एक समुदाय के रूप में, हमें आपस में एकीकरण परीक्षण का एक हिस्सा वितरित करना चाहिए। अधिकांश आश्रितों के लिए पैकेज निर्भरता के लिए आने वाले सभी अद्यतनों के साथ अपने पैकेज को बैठना और परीक्षण करना संभव नहीं है। यही कारण है कि पुस्तकालय डेवलपर्स को संस्करणों को प्रतिबद्ध नहीं करना चाहिए और रिपॉजिटरी को अपनी निर्भरता नहीं करनी चाहिए। हमें स्थानीय रूप से निर्भरता को अपडेट करने और बग रिपोर्ट भेजने के लिए नए लोगों की आवश्यकता है। हमें समुदाय को आगे बढ़ने और नवीनतम संस्करणों और नए पैकेजों के काटने पर बने रहने की आवश्यकता है।

केवल परिनियोजन की आवश्यकता वाले अनुप्रयोगों को भंडार_ नोड्यूल को भंडार में संग्रहित करना चाहिए। पैकेज अनुरक्षकों को अपनी निर्भरता के लिए स्वीकार्य संस्करण सीमाओं के लिए खुद को तय करना जारी रखना चाहिए। नोड में हम जो परिवर्तन और सुधार देखते हैं उनकी संख्या के साथ समुदाय को आकार में रखने का यह एकमात्र तरीका है।

क्या भंडार में नोड_मॉड्यूल्स के भंडारण से स्रोत पेड़ में बहुत अधिक कचरा पैदा होता है जो मेरे आवेदन से संबंधित नहीं है?

नहीं, आप गलत हैं, इस कोड का उपयोग आपके एप्लिकेशन द्वारा किया जाता है, यह आपके एप्लिकेशन का हिस्सा है, यदि आप यह दिखाते हैं कि यह नहीं है, तो यह समस्या पैदा करेगा। आप अन्य लोगों के कोड पर निर्भर करते हैं, और वे गलतियाँ करते हैं और नए कीड़े पैदा करते हैं जो आपसे कम नहीं हैं, शायद और भी अधिक बार। रिपॉजिटरी में सभी कोड को स्टोर करने से आपको हर उस लाइन पर नज़र रखने की सुविधा मिलती है, जो आपके आवेदन में कभी बदली है। यह आपको स्थानीय रूप से गिट बायसेक्ट का उपयोग करने की अनुमति देगा और यह सुनिश्चित करेगा कि परिणाम उत्पादन में समान है और उत्पादन में सभी मशीनें समान हैं। निर्भरता में अज्ञात परिवर्तनों का पालन करने की आवश्यकता नहीं है, सभी परिवर्तन, प्रत्येक पंक्ति में, संस्करण नियंत्रण प्रणाली के माध्यम से उपलब्ध हैं।

ठीक है, ठीक है, अब हम क्या करें?

हम संक्षेप में बताते हैं।

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

आप सभी जिन्होंने अपने .itignore से नोड_मॉड्यूल्स जोड़े हैं, आज इस बकवास को हटा दें। यह एक ऐसे युग का अवशेष है जिसे हम पीछे छोड़ कर बहुत खुश हैं। वैश्विक मॉड्यूल का युग मर चुका है।