Node.js परियोजनाएं जिनमें लॉक फ़ाइलों का उपयोग न करना बेहतर है

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

संक्षेप में सबसे महत्वपूर्ण बात

वेब सर्वर की तरह Node.js एप्लिकेशन विकसित करते समय लॉक फाइलें बेहद उपयोगी होती हैं। हालाँकि, यदि आप npm में प्रकाशन के लक्ष्य के साथ एक लाइब्रेरी या कमांड-लाइन टूल बनाने की बात कर रहे हैं, तो आपको यह जानना होगा कि npm में लॉक फाइलें प्रकाशित नहीं हैं। इसका मतलब है कि यदि इन फ़ाइलों का उपयोग विकास के दौरान किया जाता है, तो npm पैकेज के निर्माता, और जो इस पैकेज का उपयोग करते हैं, वे निर्भरता के विभिन्न संस्करणों का उपयोग करेंगे।

लॉक फाइल क्या है?

लॉक फ़ाइल प्रोजेक्ट में काम के दौरान प्राप्त किए गए फॉर्म में पूर्ण निर्भरता के पेड़ का वर्णन करती है। इस विवरण में नेस्टेड निर्भरताएं भी शामिल हैं। फ़ाइल में उपयोग किए गए पैकेज के विशिष्ट संस्करणों के बारे में जानकारी है। एनपीएम पैकेज मैनेजर में, ऐसी फाइलों को यार्न - यार्न में package-lock.json कहा जाता है। दोनों प्रबंधकों में, ये फ़ाइलें एक ही फ़ोल्डर में स्थित हैं जैसे कि package.json ।

यहाँ package-lock.json दिखता है।

 { "name": "lockfile-demo", "version": "1.0.0", "lockfileVersion": 1, "requires": true, "dependencies": {  "ansi-styles": {    "version": "3.2.1",    "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz",    "integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==",    "requires": {      "color-convert": "^1.9.0"    }  },  "chalk": {    "version": "2.4.2",    "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz",    "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==",    "requires": {      "ansi-styles": "^3.2.1",      "escape-string-regexp": "^1.0.5",      "supports-color": "^5.3.0"    }  } } } 

यहाँ एक उदाहरण yarn.lock फ़ाइल है। यह package-lock.json तरह डिज़ाइन नहीं किया गया है, लेकिन इसमें समान डेटा है।

 # THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY. # yarn lockfile v1 ansi-styles@^3.2.1: version "3.2.1" resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-3.2.1.tgz#41fbb20243e50b12be0f04b8dedbf07520ce841d" integrity sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA== dependencies:       color-convert "^1.9.0" chalk@^2.4.2: version "2.4.2" resolved "https://registry.yarnpkg.com/chalk/-/chalk-2.4.2.tgz#cd42541677a54333cf541a49108c1432b44c9424" integrity sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ== dependencies:       ansi-styles "^3.2.1"       escape-string-regexp "^1.0.5"       supports-color "^5.3.0" 

इन दोनों फ़ाइलों में कुछ महत्वपूर्ण निर्भरता जानकारी शामिल है:

• प्रत्येक स्थापित निर्भरता का सटीक संस्करण।
• प्रत्येक निर्भरता के लिए निर्भरता की जानकारी।
• डाउनलोड किए गए पैकेज के बारे में जानकारी, चेकसम सहित पैकेज की अखंडता को सत्यापित करने के लिए उपयोग किया जाता है।

यदि सभी आश्रितों को लॉक फ़ाइल में सूचीबद्ध किया गया है, तो वे package.json बारे में जानकारी क्यों जोड़ते हैं। दो फाइलों की आवश्यकता क्यों है?

Package.json और लॉक फ़ाइलों की तुलना

package.json फ़ाइल की dependencies क्षेत्र का उद्देश्य प्रोजेक्ट निर्भरता को दिखाना है जो इसे ठीक से काम करने के लिए स्थापित किया जाना चाहिए। लेकिन इसमें इन निर्भरताओं की निर्भरता के बारे में जानकारी शामिल नहीं है। निर्भरता की जानकारी में सटीक पैकेज संस्करण या अर्थ वर्जनिंग के नियमों के अनुसार निर्दिष्ट संस्करणों की एक निश्चित श्रृंखला शामिल हो सकती है। Npm या यार्न रेंज का उपयोग करते समय, पैकेज का सबसे उपयुक्त संस्करण चुना जाता है।

मान लीजिए कि एक निश्चित परियोजना की निर्भरता को स्थापित npm install लिए npm install कमांड चलाया गया था। स्थापना प्रक्रिया के दौरान, npm ने उपयुक्त पैकेज उठाए। यदि आप इस कमांड को थोड़ी देर के बाद फिर से चलाते हैं, और अगर इस दौरान निर्भरता के नए संस्करण जारी किए जाते हैं, तो यह अच्छी तरह से हो सकता है कि दूसरी बार प्रोजेक्ट में उपयोग किए गए पैकेज के अन्य संस्करण लोड किए गए हैं। उदाहरण के लिए, यदि आप एक निर्भरता स्थापित करते हैं, जैसे कि twilio , twilio npm install twilio का उपयोग करते हुए, package.json की dependencies अनुभाग में निम्नलिखित प्रविष्टि दिखाई दे सकती है: npm install twilio file:

 { "dependencies": {    "twilio": "^3.30.3" } } 

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

यदि npm या यार्न को संबंधित लॉक फ़ाइल मिलती है, तो वे इस फ़ाइल के आधार पर पैकेज स्थापित करेंगे, और package.json पर नहीं। यह विशेष रूप से उपयोगी है, उदाहरण के लिए, प्लेटफार्मों पर कंटीन्यूअस इंटीग्रेशन (CI) सिस्टम का उपयोग करते समय, जिस पर आपको ऐसे वातावरण में कोड और परीक्षणों का एक समान संचालन सुनिश्चित करने की आवश्यकता होती है, जिनकी विशेषताओं को पहले से जाना जाता है। ऐसे मामलों में, आप उचित पैकेज प्रबंधकों को आमंत्रित करते समय विशेष कमांड या झंडे का उपयोग कर सकते हैं:

 npm ci #   ,    package-lock.json yarn install --frozen-lock-file #  ,    yarn.lock,     

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

Npm रजिस्ट्री में पुस्तकालयों या अन्य सॉफ्टवेयर टूल्स को प्रकाशित करते समय ऐसा क्यों नहीं किया जाता है? इस प्रश्न का उत्तर देने से पहले, हमें इस बारे में बात करने की आवश्यकता है कि प्रकाशन पैकेज की प्रक्रिया कैसे काम करती है।

पैकेज प्रकाशन प्रक्रिया

कुछ डेवलपर्स का मानना ​​है कि npm में जो प्रकाशित किया गया है, वह ठीक उसी प्रकार है जो गिट रिपॉजिटरी में संग्रहित है, या इस पर काम पूरा होने के बाद प्रोजेक्ट क्या हो जाता है। वास्तव में ऐसा नहीं है। पैकेज प्रकाशित करते समय, npm को पता चलता है कि कौन-सी फाइलें संकुल कुंजी फ़ाइल में पहुँच कर प्रकाशित .npmignore हैं। फ़ाइल और .npmignore फ़ाइल। यदि इसका कोई भी पता नहीं लगाया जा सकता है, तो .gitignore फ़ाइल का उपयोग किया जाता है। इसके अलावा, कुछ फाइलें हमेशा प्रकाशित होती हैं, और कुछ कभी प्रकाशित नहीं होती हैं। आप पता लगा सकते हैं कि ये फाइलें यहां क्या हैं। उदाहरण के लिए, npm .git फ़ोल्डर को हमेशा अनदेखा करता है।

उसके बाद, npm सभी उपयुक्त फ़ाइलों को लेता है और उन्हें npm pack कमांड का उपयोग करके एक tarball फ़ाइल में npm pack । यदि आप देखना चाहते हैं कि वास्तव में ऐसी फ़ाइल में क्या पैक किया गया है, तो आप प्रोजेक्ट फ़ोल्डर में npm pack --dry-run कमांड को चला सकते हैं और कंसोल में सामग्रियों की सूची को देख सकते हैं।


Npm पैक -dry-run कमांड आउटपुट

परिणामी tarball फ़ाइल को फिर npm रजिस्ट्री पर अपलोड किया जाता है। जब आप npm pack --dry-run तो आप इस तथ्य पर ध्यान दे सकते हैं कि अगर प्रोजेक्ट में कोई package-lock.json फ़ाइल है, तो यह टारबॉल फ़ाइल में शामिल नहीं है। यह इस तथ्य के कारण है कि यह फ़ाइल, एनपीएम नियमों के अनुसार, हमेशा अनदेखा होती है।

इसका परिणाम यह है कि यदि कोई किसी और के पैकेज को स्थापित करता है, तो package-lock.json फ़ाइल शामिल नहीं होगी। इस फ़ाइल में क्या है कि पैकेज डेवलपर को किसी और द्वारा पैकेज स्थापित करने पर ध्यान नहीं दिया जाएगा।

यह, अशुभ संयोग से, उस समस्या का नेतृत्व कर सकता है जिसके बारे में हमने शुरुआत में बात की थी। डेवलपर की प्रणाली में, कोड ठीक काम करता है, और अन्य प्रणालियों में यह त्रुटियों का उत्पादन करता है। लेकिन तथ्य यह है कि प्रोजेक्ट डेवलपर और जो प्रोजेक्ट का उपयोग करते हैं वे पैकेज के विभिन्न संस्करणों का उपयोग करते हैं। इसे कैसे ठीक करें?

लॉक-फाइल के इनकार और प्रौद्योगिकी के उपयोग से हटना

पहले आपको प्रोजेक्ट रिपॉजिटरी में लॉक फ़ाइलों को शामिल करने से रोकने की आवश्यकता है। Git का उपयोग करते समय, आपको अपनी परियोजना .gitignore फ़ाइल में निम्नलिखित को शामिल करना होगा:

 yarn.lock package-lock.json 

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

आप निम्न-सामग्री के साथ .npmrc फ़ाइल को प्रोजेक्ट फ़ोल्डर में .npmrc package-lock.json फ़ाइल के स्वचालित निर्माण को अक्षम कर सकते हैं:

 package-lock=false 

यार्न के साथ काम करते समय, आप yarn install --no-lockfile उपयोग कर सकते हैं yarn install --no-lockfile , जो आपको yarn install --no-lockfile की रीडिंग को अक्षम करने की अनुमति देता है। फ़ाइल।

हालाँकि, इस तथ्य से कि हमें package-lock.json से छुटकारा मिल गया है। package-lock.json फ़ाइल का मतलब यह नहीं है कि हम निर्भरता के बारे में जानकारी पर कब्जा नहीं कर सकते और निर्भरता को कम कर सकते हैं। एक और फाइल है जिसका नाम npm-shrinkwrap.json ।

सामान्य तौर पर, यह package-lock.json रूप में एक ही फाइल package-lock.json । इसे package-lock.json द्वारा निर्मित किया जाता है। पैकेज प्रकाशित होने पर यह फ़ाइल npm रजिस्ट्री में मिलती है।

इस ऑपरेशन को स्वचालित करने के लिए, npm सिक्रेटवैप कमांड को package.json की स्क्रिप्ट विवरण अनुभाग में जोड़ा जा सकता है। प्रीपोन स्क्रिप्ट के रूप में json फाइल। गिट कम हुक का उपयोग करके आप एक ही प्रभाव प्राप्त कर सकते हैं। परिणामस्वरूप, आप सुनिश्चित कर सकते हैं कि आपके विकास के वातावरण में, आपके CI-सिस्टम में, और आपके प्रोजेक्ट के उपयोगकर्ता समान निर्भरता का उपयोग करते हैं।

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

पैकेज और निर्भरता की जानकारी प्राप्त करना

दुर्भाग्य से, npm प्रलेखन में निर्भरता प्रबंधन के बारे में जानकारी के सभी धन के साथ, इस जानकारी को नेविगेट करना कभी-कभी मुश्किल होता है। यदि आप जानना चाहते हैं कि निर्भरता की स्थापना के दौरान वास्तव में क्या स्थापित किया गया है या पैकेज को npm पर भेजने से पहले पैक किया गया है, तो आप अलग-अलग कमांडों के साथ --dry-run फ्लैग का उपयोग कर सकते हैं। इस ध्वज का उपयोग इस तथ्य की ओर जाता है कि टीम सिस्टम को प्रभावित नहीं करती है। उदाहरण के लिए, npm install --dry-run कमांड वास्तव में निर्भरताएं स्थापित नहीं करता है, और npm publish --dry-run कमांड पैकेज प्रकाशन प्रक्रिया शुरू नहीं करता है।

यहां कुछ समान आदेश दिए गए हैं:

 npm ci --dry-run #  ,   package-lock.json   npm-shrinkwrap.json npm pack --dry-run #     ,       npm install <dep> --verbose --dry-run #            

परिणाम

हमने यहां जिस बारे में बात की है, वह एनपीएम का उपयोग करके विभिन्न कार्यों को करने की बारीकियों पर निर्भर करता है। हम पैकेजिंग, प्रकाशन, पैकेज स्थापित करने, निर्भरता के साथ काम करने के बारे में बात कर रहे हैं। और इस तथ्य को देखते हुए कि npm लगातार विकसित हो रहा है, हम कह सकते हैं कि यह सब भविष्य में बदल सकता है। इसके अलावा, यहां दी गई सिफारिशों के व्यावहारिक अनुप्रयोग की संभावना इस बात पर निर्भर करती है कि पैकेज डेवलपर विभिन्न वातावरणों में निर्भरता के विभिन्न संस्करणों का उपयोग करने की समस्या को कैसे मानता है।

उम्मीद है कि इस सामग्री ने आपको बेहतर तरीके से समझने में मदद की है कि एनपीएम निर्भरता पारिस्थितिकी तंत्र कैसे काम करता है। यदि आप इस प्रश्न पर और भी गहरा खुलासा करना चाहते हैं - यहाँ आप npm ci और npm install कमांड के बीच अंतर के बारे में पढ़ सकते हैं। यहां आप यह package-lock.json सकते हैं कि package-lock.json और npm-shrinkwrap.json package-lock.json npm-shrinkwrap.json में वास्तव में क्या मिलता है। यहां npm प्रलेखन पृष्ठ है जहां आप यह पता लगा सकते हैं कि कौन सी परियोजना फाइलें शामिल हैं और पैकेज में शामिल नहीं हैं।

प्रिय पाठकों! क्या आप अपनी परियोजनाओं में npm-compresswrap.json फ़ाइल का उपयोग करते हैं?