🍆 🕥 🔞 नरक जावास्क्रिप्ट निर्भरता के लिए सड़क 🎅🏿 👆🏾 🎛️

प्रत्येक जावास्क्रिप्ट परियोजना अच्छे इरादों के साथ शुरू होती है, जिसका अर्थ है कि इसके निर्माता अपने विकास के दौरान बहुत सारे एनपीएम पैकेज का उपयोग न करने का वादा करते हैं। लेकिन भले ही डेवलपर्स इस वादे को निभाने के लिए काफी प्रयास करते हैं, लेकिन एनपीएम पैकेज धीरे-धीरे उनकी परियोजनाओं में प्रवेश करते हैं। फ़ाइल का आकार package.jsonसमय के साथ बढ़ता है। और package-lock.jsonनिर्भरता की स्थापना के बाद से , एक वास्तविक हॉरर होता है, पैकेज के अतिरिक्त और विलोपन में व्यक्त किया जाता है, विशेष रूप से अगले पीआर के साथ ध्यान देने योग्य ... "सब कुछ ठीक है," टीम लीडर का कहना है। बाकी टीम समझौते में सिर हिलाती है। और क्या करना है? हम सभी इस तथ्य का आनंद लेते हैं कि जावास्क्रिप्ट पारिस्थितिकी तंत्र जीवित और अच्छी तरह से है। हमें हर बार पहिया को सुदृढ़ करने की आवश्यकता नहीं है और उन समस्याओं को हल करने का प्रयास करें जो पहले से ही खुले स्रोत समुदाय द्वारा हल किए गए हैं।

मान लीजिए आप एक ब्लॉग बनाने जा रहे हैं और Gatsby.js का उपयोग करना चाहते हैं। अपने प्रोजेक्ट के आधार पर इस साइट जनरेटर को जोड़ने का प्रयास करें। अब, बधाई। आपकी परियोजना में सिर्फ 19,000 अतिरिक्त निर्भरताएँ थीं। यह सामान्य बात है? जावास्क्रिप्ट निर्भरता पेड़ कितना जटिल हो सकता है? एक निर्भरता का पेड़ नरक में कैसे बदल जाता है? चलिए इसका पता लगाते हैं।

जावास्क्रिप्ट पैकेज क्या है?

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

लोकप्रिय रजिस्ट्रियों में पैकेजों की संख्या पर डेटा

आप सोच सकते हैं कि इस ग्राफ़ पर बहुत बड़ी मात्रा में कोड का प्रतिनिधित्व किया जाता है। जिस तरह से यह है। किसी प्रोजेक्ट को NPM पैकेज में बदलने के लिए, इस पैकेज में एक फ़ाइल होनी चाहिएpackage.json। इस तरह के पैकेज को एनपीएम रजिस्ट्री को भेजा जा सकता है।

Package.json क्या है?

यहां ऐसे कार्य हैं जो हल करते हैं package.json:

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

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

शायद इस बात पर निर्भर करता है कि इस फाइल में परियोजना की निर्भरताएँ कुछ खतरनाक दिखती हैं। कल्पना करें कि एक पैकेज है जो दूसरे पैकेज पर निर्भर करता है, और यह अन्य पैकेज दूसरे पैकेज पर निर्भर करता है। निर्भरता की ऐसी श्रृंखला मनमाने ढंग से लंबी हो सकती है। इस कारण से, एकमात्र पैकेज, Gatsby.js को स्थापित करने का अर्थ है कि परियोजना को 19,000 अतिरिक्त निर्भरताओं से लैस करना।

पैकेज में निर्भरता प्रकार। json

यह समझने के लिए कि परियोजना निर्भरता सूची समय के साथ कैसे बढ़ती है, आइए विभिन्न प्रकार की निर्भरता के बारे में बात करते हैं जो एक परियोजना हो सकती है। अर्थात्, package.jsonनिम्नलिखित खंड मिल सकते हैं जो विभिन्न निर्भरता का वर्णन करते हैं:

dependencies - ये साधारण निर्भरताएं हैं, जिनमें से कार्यक्षमता का उपयोग परियोजना में किया जाता है, और जो इसके कोड से एक्सेस की जाती हैं।
devDependencies- ये विकास पर निर्भरताएं हैं। उदाहरण के लिए, प्रीटियर लाइब्रेरी का उपयोग कोड को प्रारूपित करने के लिए किया जाता है।
peerDependencies - यदि इस खंड पर निर्भरताएं लिखी जाती हैं, तो पैकेज डेवलपर को सूचित करता है कि वह कौन स्थापित करेगा कि उसे इस खंड में निर्दिष्ट पैकेज के एक विशिष्ट संस्करण की आवश्यकता होगी।
optionalDependencies - वे वैकल्पिक निर्भरता को सूचीबद्ध करते हैं, जैसे, स्थापित करने में असमर्थता जो पैकेज की स्थापना प्रक्रिया का उल्लंघन नहीं करेगी।
bundledDependencies — , . , NPM, , .

package-lock.json

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

एक ऐसी परियोजना पर विचार करें जिसकी निर्भरता में रिएक्ट शामिल हो। इसी प्रविष्टि पर उपलब्ध है package.json। यदि आप फ़ाइल को देखते हैंpackage-lock.json इस परियोजना के बाद, आप निम्न की तरह कुछ देख सकते हैं:

    "react": {
      "version": "16.13.0",
      "resolved": "https://registry.npmjs.org/react/-/react-16.13.0.tgz",
      "integrity": "sha512-TSavZz2iSLkq5/oiE7gnFzmURKZMltmi193rm5HEoUDAXpzT9Kzw6oNZnGoai/4+fUnm7FqS5dwgUL34TujcWQ==",
      "requires": {
        "loose-envify": "^1.1.0",
        "object-assign": "^4.1.1",
        "prop-types": "^15.6.2"
      }
    }

एक फ़ाइल package-lock.jsonपरियोजना निर्भरता की एक बड़ी सूची है। यहां मॉड्यूल के लिए निर्भरता संस्करण, पथ (यूआरआई), मॉड्यूल की अखंडता और इस मॉड्यूल द्वारा आवश्यक पैकेजों को सत्यापित करने के लिए उपयोग किए गए हैश हैं। यदि आप इस फ़ाइल को पढ़ते हैं, तो आपको उन सभी पैकेजों के रिकॉर्ड मिल सकते हैं जिनकी प्रतिक्रिया की आवश्यकता है। यह वह जगह है जहाँ निर्भरता का असली नरक निहित है। परियोजना की जरूरत की हर चीज यहां बताई गई है।

Gatsby.js निर्भरता को समझना

यह कैसे है कि, केवल एक निर्भरता स्थापित करने के बाद, हम परियोजना में 19,000 निर्भरताएं जोड़ते हैं? यह सब निर्भरता निर्भरता के बारे में है। इसलिए हमारे पास वही है जो हमारे पास है:

$ npm install --save gatsby

...

+ gatsby@2.19.28
added 1 package from 1 contributor, removed 9 packages, updated 10 packages and audited 19001 packages in 40.382s

यदि आप में देखते हैं package.json, तो आप केवल एक निर्भरता पा सकते हैं। लेकिन अगर आप इसे देखते हैं package-lock.json, तो यह पता चलता है कि हमारे सामने लगभग 14-किलोबाइट राक्षस है। कोड के उन सभी लाइनों के बारे में अधिक विस्तृत उत्तर जो अर्थ में आते हैं package-lock.json, उन्हें Gatsby.js रिपॉजिटरीpackage.json में फ़ाइल में पाया जा सकता है । Npm की गणना के अनुसार , कई तरह की प्रत्यक्ष निर्भरताएं हैं, 132. यदि इन निर्भरताओं में से प्रत्येक में कम से कम एक और निर्भरता है, तो परियोजना निर्भरता की कुल संख्या दोगुनी हो जाएगी - और इसमें 264 निर्भरताएं होंगी। बेशक, वास्तविक दुनिया में ऐसा नहीं है। प्रत्येक प्रत्यक्ष परियोजना निर्भरता में 1 से अधिक अंतर्निहित निर्भरता होती है। नतीजतन, परियोजना निर्भरता की सूची बहुत लंबी है।

उदाहरण के लिए, हम इस बात में रुचि लेते हैं कि दर्ज पैकेज को कितनी बार अन्य पैकेजों के लिए निर्भरता के रूप में उपयोग किया जाता है :

$ npm ls lodash
example-js-package@1.0.0
└─┬ gatsby@2.19.28
  ├─┬ @babel/core@7.8.6
  │ ├─┬ @babel/generator@7.8.6
  │ │ └── lodash@4.17.15  deduped
  │ ├─┬ @babel/types@7.8.6
  │ │ └── lodash@4.17.15  deduped
  │ └── lodash@4.17.15  deduped
  ├─┬ @babel/traverse@7.8.6
  │ └── lodash@4.17.15  deduped
  ├─┬ @typescript-eslint/parser@2.22.0
  │ └─┬ @typescript-eslint/typescript-estree@2.22.0
  │   └── lodash@4.17.15  deduped
  ├─┬ babel-preset-gatsby@0.2.29
  │ └─┬ @babel/preset-env@7.8.6
  │   ├─┬ @babel/plugin-transform-block-scoping@7.8.3
  │   │ └── lodash@4.17.15  deduped
  │   ├─┬ @babel/plugin-transform-classes@7.8.6
  │   │ └─┬ @babel/helper-define-map@7.8.3
  │   │   └── lodash@4.17.15  deduped
  │   ├─┬ @babel/plugin-transform-modules-amd@7.8.3
  │   │ └─┬ @babel/helper-module-transforms@7.8.6
  │   │   └── lodash@4.17.15  deduped
  │   └─┬ @babel/plugin-transform-sticky-regex@7.8.3
  │     └─┬ @babel/helper-regex@7.8.3
  │       └── lodash@4.17.15  deduped
  ...

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

$ du -sh node_modules
200M    node_modules

200 मेगाबाइट इतना बुरा नहीं है। मैंने देखा कि कैसे इस फ़ोल्डर का आकार आसानी से 700 एमबी तक पहुंच जाता है। यदि आप यह जानने में रुचि रखते हैं कि कौन से मॉड्यूल सबसे अधिक स्थान लेते हैं, तो आप निम्नलिखित कमांड चला सकते हैं:

$ du -sh ./node_modules/* | sort -nr | grep '\dM.*'
 17M    ./node_modules/rxjs
8.4M    ./node_modules/@types
7.4M    ./node_modules/core-js
6.8M    ./node_modules/@babel
5.4M    ./node_modules/gatsby
5.2M    ./node_modules/eslint
4.8M    ./node_modules/lodash
3.6M    ./node_modules/graphql-compose
3.6M    ./node_modules/@typescript-eslint
3.5M    ./node_modules/webpack
3.4M    ./node_modules/moment
3.3M    ./node_modules/webpack-dev-server
3.2M    ./node_modules/caniuse-lite
3.1M    ./node_modules/graphql
...

हाँ, rxjs एक कपटी पैकेज है।

यहां एक सरल कमांड है जो फ़ोल्डर के आकार को कम करने node_modulesऔर इसकी संरचना को सरल बनाने में मदद करता है :

$ npm dedup
moved 1 package and audited 18701 packages in 4.622s

51 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

समर्पण के दौरान , एनपीएम निर्भरता के पेड़ की संरचना को सरल बनाने की कोशिश करता है ताकि अन्य निर्भरताओं द्वारा उपयोग की जाने वाली निर्भरता का पता लगाकर उन्हें स्थानांतरित किया जा सके ताकि उन्हें साझा किया जा सके। यह हमारे लॉश उदाहरण पर लागू होता है। कई पैकेजों का उपयोग किया जाता है lodash @4.17.15, परिणामस्वरूप, उनकी संचालन क्षमता सुनिश्चित करने के लिए, यह केवल एक बार पुस्तकालय के इस संस्करण को स्थापित करने के लिए पर्याप्त है। बेशक, यह ऐसी स्थिति है जो हम शुरुआत से ही निर्भर करते हैं, केवल निर्भरता की स्थापना से। यदि किसी परियोजना पर काम करने की प्रक्रिया में package.jsonनई निर्भरताएं जुड़ती हैं, तो टीम को याद रखने के लिए कभी-कभी सिफारिश की जाती है npm dedup। यदि आप यार्न पैकेज मैनेजर का उपयोग करते हैं, तो एक समान कमांड यार्न कटौती की तरह दिखता है। लेकिन, वास्तव में, इसकी कोई आवश्यकता नहीं है, क्योंकि कमांड निष्पादित होने पर निर्भरता अनुकूलन स्वचालित रूप से किया जाता है yarn install।

निर्भरता दृश्य

अपनी परियोजना की निर्भरता के चित्रमय प्रतिनिधित्व में रुचि रखते हैं? यदि हां, तो आप विशेष उपकरणों का उपयोग करके ऐसी प्रस्तुति बना सकते हैं। आइए उनमें से कुछ पर विचार करें।

निम्नलिखित npm.anvaka.com/ का उपयोग करके प्राप्त की गई निर्भरता दृश्यता है ।

Npm.anvaka.com का उपयोग करते हुए निर्भरता दृश्य।

यहां आप Gatsby.js परियोजना पैकेज निर्भरता की निर्भरता देख सकते हैं। परिणाम एक विशाल वेब के समान है। Gatsby.js परियोजना में इतनी निर्भरताएँ हैं कि यह "वेब" लगभग मेरा ब्राउज़र "लटका" है। अब , यदि रुचि है, तो इस आरेख का एक लिंक। इसे 3 डी-फॉर्म में प्रस्तुत किया जा सकता है।

यहाँ npm.broofa.com का उपयोग करके बनाया गया एक दृश्य है।

Npm.broofa.com का उपयोग करके बनाए गए एक निर्भरता दृश्य का एक टुकड़ा

यह एक फ़्लोचार्ट के समान है। वह, Gatsby.js के लिए, बहुत जटिल हो जाती है। आप इसे यहां देख सकते हैं। सर्किट तत्वों को npms.io के अनुमानों के आधार पर रंगीन किया जा सकता है। आप अपनी खुद की फ़ाइल साइट पर अपलोड कर सकते हैंpackage.json। पैकेज फोबिया

टूलआपको यह पता लगाने की अनुमति देता है कि पैकेज स्थापित करने से पहले इसे कितनी जगह चाहिए।

पैकेज फोबिया का उपयोग करके प्राप्त पैकेज की जानकारी

यहां आप प्रकाशित पैकेज के आकार के बारे में पता कर सकते हैं, और स्थापना के बाद इसे कितना डिस्क स्थान ले जाएगा।

नीचे पंक्ति: महान शक्ति के साथ बड़ी जिम्मेदारी आती है

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

अब जब आप इस बिंदु तक पढ़ चुके हैं, तो आपको npm-project निर्भरता ट्री संरचना की विशेषताओं के बारे में अधिक समझ होनी चाहिए। यदि आप उस प्रोजेक्ट में एक लाइब्रेरी जोड़ते हैं जो बहुत बड़ी है, या यदि आप सिर्फ अपनी परियोजना की निर्भरता का पता लगाते हैं, तो आप हमेशा इस बात का लाभ उठा सकते हैं कि हमने यहाँ क्या चर्चा की है और निर्भरता का विश्लेषण करें।

प्रिय पाठकों! क्या आप अपने npm प्रोजेक्ट्स में अधिक से अधिक निर्भरता का उपयोग करना चाहते हैं?

नरक जावास्क्रिप्ट निर्भरता के लिए सड़क