npm को VPN नहीं, पैकेज स्कोप के अनुसार रजिस्ट्री चुनने दें

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

दो नाम, दो गंतव्य

npm पैकेज के नाम में या तो स्कोप होता है या नहीं। स्कोप वाला नाम @ चिह्न और स्कोप पहचानकर्ता से शुरू होता है, और वही पहचानकर्ता है जिसे कॉन्फ़िगरेशन मैप कर सकती है। पैकेज की कोई और बात मैपिंग के लिए मायने नहीं रखती। रजिस्ट्री कभी यह देखकर अनुरोध नहीं देखती कि पैकेज आंतरिक है या सार्वजनिक; वह केवल एक नाम देखती है।

इसलिए नीचे दी गई फ़ाइल तीन पंक्तियों में दो इरादे व्यक्त करती है: सार्वजनिक पैकेज सार्वजनिक रजिस्ट्री में जाते हैं, और कंपनी स्कोप के अंतर्गत पैकेज उस होस्ट के लिए टोकन के साथ कंपनी की रजिस्ट्री में जाते हैं।

registry=https://registry.npmjs.org/
@acme:registry=https://packages.corp.example/
//packages.corp.example/:_authToken=${NPM_TOKEN}

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

मैपिंग और नेटवर्क को अपने मन में अलग खानों में रखें। स्कोप प्रविष्टि किसी अगम्य होस्ट को गम्य नहीं बना सकती, और काम करने वाली सुरंग npm को नहीं बता सकती कि पैकेज किस रजिस्ट्री का है।

फ़ाइल को सही क्रम में लिखें

npm कई फ़ाइलें पढ़ता है फिर भी अपने तर्क में प्रोजेक्ट फ़ाइल को पहले रखें। प्रोजेक्ट निर्देशिका की .npmrc वही है जो आपके सहकर्मी रिपॉज़िटरी के माध्यम से प्राप्त करते हैं, इसलिए उसे आपके निजी टोकन के बजाय साझा नीति व्यक्त करनी चाहिए। वही फ़ाइल वह भी है जिसे समीक्षक पढ़ेगा। उसे एक नज़र में समीक्षा करने लायक छोटा रखें।

संगठन ने अलग निर्णय न लिया हो तो डिफ़ॉल्ट registry पंक्ति को सार्वजनिक रजिस्ट्री की ओर इंगित रहने दें। उसे हटाने से मशीन इस पर निर्भर हो जाती है कि उपयोगकर्ता-स्तर की फ़ाइल क्या कहती है, और यही वह निहित निर्भरता है जो दो लैपटॉप पर अलग परिणाम देती है।

स्कोप पंक्ति वाइल्डकार्ड नहीं है। स्कोप के बाहर का नाम डिफ़ॉल्ट का उपयोग जारी रखता है, और यही वह व्यवहार है जो आप हर उस निर्भरता के लिए चाहते हैं जो आपने स्वयं नहीं लिखी।

फ़ाइल को कमिट करने से पहले जाँचें कि वह किसमें हल होती है, वास्तविक इंस्टॉल के बजाय एक फेंकने योग्य पैकेज नाम का उपयोग करके, ताकि गलती का कोई मूल्य न हो।

क्रेडेंशियल प्रोजेक्ट के नहीं, होस्ट के होते हैं

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

पर्यावरण चर का उपयोग शाब्दिक टोकन को रिपॉज़िटरी की फ़ाइल से बाहर रखता है। यह टोकन को हर जगह अदृश्य नहीं बनाता; वह अब भी प्रक्रिया पर्यावरण में दिखता है, और कॉन्फ़िगरेशन प्रिंट करने वाला कोई आदेश उसे उजागर कर सकता है।

चर को संगठन द्वारा अनुमोदित किसी भी स्थानीय या CI क्रेडेंशियल तंत्र के माध्यम से प्रदान करें, और कभी भी वास्तविक टोकन ऐसे उदाहरण में न चिपकाएँ जिसे दस्तावेज़ीकरण में कॉपी किया जा सके।

यदि दो रजिस्ट्रियाँ खेल में हैं, तो प्रत्येक को अपनी प्रविष्टि मिलती है। एक भी अपात्र टोकन सेटिंग सर्वोत्तम स्थिति में अस्पष्ट है और सबसे खराब स्थिति में गलत होस्ट पर भेजी जाती है।

जब गलत रजिस्ट्री जीतती है

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

पर्यावरण चर CI में सामान्य दोषी है, जहाँ कोई जॉब रजिस्ट्री एक बार सेट करता है और हर बाद का चरण उसे प्राप्त करता है। दूसरा सबसे सामान्य डेवलपर की मशीन पर उपयोगकर्ता-स्तर की फ़ाइल है जो रिपॉज़िटरी के कहने को ओवरराइड करती है।

किसी और चीज़ को डीबग करने से पहले एक स्कोप वाले और एक स्कोप रहित नाम के लिए प्रभावी कॉन्फ़िगरेशन और हल की गई रजिस्ट्री प्रिंट करें। यदि वे दो उत्तर वही हैं जिनकी आप अपेक्षा करते हैं, तो समस्या नेटवर्क है; यदि नहीं, तो समस्या कॉन्फ़िगरेशन है और कोई भी VPN कार्य मदद नहीं करेगा।

कमिट करने से पहले चेकलिस्ट

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

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

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