TL; DR: रोजमर्रा के उपयोग में सबसे बड़ा अंतर नेस्टेड निर्भरता नहीं है ... यह मॉड्यूल और ग्लोबल्स के बीच का अंतर है।
मुझे लगता है कि पिछले पोस्टर्स में कुछ बुनियादी अंतरों को अच्छी तरह से कवर किया गया है। (npm की नेस्टेड निर्भरता का उपयोग वास्तव में बड़े, जटिल अनुप्रयोगों के प्रबंधन में बहुत सहायक है, हालांकि मुझे नहीं लगता कि यह सबसे महत्वपूर्ण अंतर है।)
मुझे आश्चर्य है, हालांकि, किसी ने भी स्पष्ट रूप से बावर और एनपीएम के बीच के सबसे बुनियादी भेदों में से एक को नहीं समझाया है। यदि आप ऊपर दिए गए उत्तर पढ़ते हैं, तो आप अक्सर npm के संदर्भ में 'मॉड्यूल' शब्द देखेंगे। लेकिन यह आकस्मिक रूप से उल्लिखित है, जैसे कि यह केवल एक सिंटैक्स अंतर हो सकता है।
लेकिन मॉड्यूल बनाम ग्लोबल्स (या मॉड्यूल बनाम 'स्क्रिप्ट') का यह अंतर संभवतः बोवर और एनपीएम के बीच सबसे महत्वपूर्ण अंतर है। मॉड्यूल में सब कुछ डालने का npm दृष्टिकोण आपको ब्राउज़र के लिए जावास्क्रिप्ट लिखने के तरीके को बदलने की आवश्यकता है, लगभग निश्चित रूप से बेहतर के लिए।
द बोवर अप्रोच: ग्लोबल रिसोर्सेज, लाइक <script>टैग
मूल में, बोवर सादे-पुरानी स्क्रिप्ट फ़ाइलों को लोड करने के बारे में है। जो भी स्क्रिप्ट फाइलें होती हैं, बोवर उन्हें लोड करेगा। मूल रूप से जिसका अर्थ है कि बोवर सादे पुराने में अपने सभी लिपियों सहित की तरह है <script>'में है <head>अपने HTML के।
तो, वही मूल दृष्टिकोण जिसका आप उपयोग कर रहे हैं, लेकिन आपको कुछ अच्छी स्वचालन सुविधाएं मिलेंगी:
- आपको अपने प्रोजेक्ट रेपो (विकास करते समय) में JS निर्भरता को शामिल करने या CDN के माध्यम से प्राप्त करने की आवश्यकता थी। अब, आप रेपो में उस अतिरिक्त डाउनलोड भार को छोड़ सकते हैं, और कोई व्यक्ति
bower installस्थानीय स्तर पर त्वरित और त्वरित रूप से कर सकता है।
- यदि एक बोवर निर्भरता तो इसमें अपनी निर्भरताएं निर्दिष्ट करती हैं
bower.json, जिन्हें आपके लिए भी डाउनलोड किया जाएगा।
लेकिन इसके अलावा, बोवर नहीं बदलता है कि हम जावास्क्रिप्ट कैसे लिखते हैं । बोवर द्वारा भरी गई फाइलों के अंदर क्या जाता है, इसके बारे में कुछ भी नहीं बदलना चाहिए। विशेष रूप से, इसका अर्थ है कि बोवर द्वारा लोड की गई लिपियों में उपलब्ध कराए गए संसाधन (आमतौर पर, लेकिन हमेशा नहीं) अभी भी वैश्विक चर के रूप में परिभाषित किए जाएंगे , जो ब्राउज़र निष्पादन के संदर्भ में कहीं से भी उपलब्ध हैं।
एनपीएम दृष्टिकोण: सामान्य जेएस मॉड्यूल, स्पष्ट निर्भरता इंजेक्शन
नोड भूमि में सभी कोड (और इस प्रकार एनपीएम के माध्यम से लोड किए गए सभी कोड) को मॉड्यूल के रूप में संरचित किया जाता है (विशेष रूप से, कॉमनजस मॉड्यूल प्रारूप के कार्यान्वयन के रूप में , या अब, ईएस 6 मॉड्यूल के रूप में)। इसलिए, यदि आप ब्राउज़र-साइड निर्भरता (ब्राउज़र के माध्यम से या कुछ और जो समान काम करते हैं) को संभालने के लिए एनपीएम का उपयोग करते हैं, तो आप अपने कोड को उसी तरह से संरचना करेंगे जैसे नोड करता है।
होशियार लोगों की तुलना में मैंने 'क्यों मॉड्यूल?' के सवाल को निपटाया है, लेकिन यहाँ एक कैप्सूल सारांश है:
- एक मॉड्यूल के अंदर कुछ भी प्रभावी रूप से नाम दिया गया है , जिसका अर्थ है कि यह कोई वैश्विक चर नहीं है, और आप गलती से इसे संदर्भित किए बिना नहीं कर सकते।
- एक मॉड्यूल के अंदर कुछ भी जानबूझकर एक विशेष संदर्भ (आमतौर पर एक अन्य मॉड्यूल) में इंजेक्ट किया जाना चाहिए ताकि इसका उपयोग किया जा सके
- इसका मतलब है कि आपके आवेदन के विभिन्न हिस्सों में एक ही बाहरी निर्भरता (लॉश, मान लें) के कई संस्करण हो सकते हैं और वे टकराव / संघर्ष नहीं करेंगे। (यह आश्चर्यजनक रूप से अक्सर होता है, क्योंकि आपका अपना कोड एक निर्भरता के एक संस्करण का उपयोग करना चाहता है, लेकिन आपकी बाहरी निर्भरता में से एक दूसरे को निर्दिष्ट करता है जो टकराव करता है। या आपको दो बाहरी निर्भरताएं मिली हैं जो प्रत्येक एक अलग संस्करण चाहते हैं।)
- क्योंकि सभी निर्भरता मैन्युअल रूप से एक विशेष मॉड्यूल में इंजेक्ट की जाती है, इसलिए उनके बारे में तर्क करना बहुत आसान है। आप एक तथ्य के लिए जानते हैं: "इस पर काम करते समय एकमात्र कोड पर विचार करने की आवश्यकता है जो मैंने जानबूझकर यहां इंजेक्शन लगाने के लिए चुना है" ।
- क्योंकि यहां तक कि इंजेक्ट किए गए मॉड्यूल की सामग्री को उस चर के पीछे एनकैप्सुलेट किया गया है जिसे आप इसे असाइन करते हैं, और सभी कोड एक सीमित दायरे के अंदर निष्पादित होते हैं, आश्चर्य और टकराव बहुत असंभव हो जाते हैं। यह बहुत कम है, संभावना है कि आपके किसी आश्रित से कुछ गलती से एक वैश्विक चर को फिर से परिभाषित किए बिना आपको इसे साकार कर देगा, या कि आप ऐसा करेंगे। (यह हो सकता है, लेकिन आपको आमतौर पर इसे करने के लिए अपने रास्ते से बाहर जाना पड़ता है, कुछ इस तरह से
window.variable। एक दुर्घटना जो अभी भी होती है वह असाइन करना है this.variable, यह एहसास नहीं है कि thisवास्तव windowमें वर्तमान संदर्भ में है।)
- जब आप एक व्यक्तिगत मॉड्यूल का परीक्षण करना चाहते हैं, तो आप आसानी से जान सकते हैं: वास्तव में और क्या (निर्भरताएं) मॉड्यूल के अंदर चलने वाले कोड को प्रभावित कर रहा है? और, क्योंकि आप स्पष्ट रूप से सब कुछ इंजेक्ट कर रहे हैं, आप आसानी से उन निर्भरताओं का मजाक उड़ा सकते हैं।
मेरे लिए, फ्रंट-एंड कोड के लिए मॉड्यूल का उपयोग उबलता है: एक बहुत ही संकीर्ण संदर्भ में काम करना जो कि कारण और परीक्षण के लिए आसान है, और जो चल रहा है उसके बारे में अधिक निश्चितता है।
कॉमनजस / नोड मॉड्यूल सिंटैक्स का उपयोग करना सीखने में केवल 30 सेकंड लगते हैं। किसी दिए गए JS फ़ाइल के अंदर, जो एक मॉड्यूल होने जा रहा है, आप पहले किसी भी बाहरी निर्भरता को घोषित करते हैं जिसका आप उपयोग करना चाहते हैं, जैसे:
var React = require('react');
फ़ाइल / मॉड्यूल के अंदर, आप सामान्य रूप से जो कुछ भी करते हैं, और कुछ वस्तु या फ़ंक्शन बनाते हैं, जिसे आप बाहरी उपयोगकर्ताओं के लिए उजागर करना चाहते हैं, शायद यह कहते हुए myModule।
किसी फ़ाइल के अंत में, आप जो कुछ भी दुनिया के साथ साझा करना चाहते हैं, उसे इस तरह निर्यात करते हैं:
module.exports = myModule;
फिर, ब्राउज़र में एक कॉमनजेस-आधारित वर्कफ़्लो का उपयोग करने के लिए, आप उन सभी व्यक्तिगत मॉड्यूल फ़ाइलों को हथियाने के लिए Browserify जैसे उपकरणों का उपयोग करेंगे, रनटाइम पर अपनी सामग्री को एनकैप्सुलेट करेंगे, और आवश्यकतानुसार एक-दूसरे में इंजेक्ट करेंगे।
और, चूंकि ES6 मॉड्यूल (जिसे आप Babel या इसी तरह ES5 के साथ ट्रांसपाइल की संभावना है) व्यापक स्वीकृति प्राप्त कर रहे हैं, और ब्राउज़र या नोड 4.0 दोनों में काम करते हैं, हमें उन लोगों के एक अच्छे अवलोकन का भी उल्लेख करना चाहिए ।
इस डेक में मॉड्यूल के साथ काम करने के लिए पैटर्न के बारे में अधिक ।
EDIT (फरवरी 2017): फेसबुक का यार्न इन दिनों npm के लिए एक बहुत ही महत्वपूर्ण संभावित प्रतिस्थापन / पूरक है: तेज, निर्धारक, ऑफ़लाइन पैकेज-प्रबंधन जो npm आपको देता है उस पर बनाता है। यह किसी भी जेएस परियोजना के लिए देखने लायक है, खासकर जब से इसे / बाहर स्वैप करना इतना आसान है।
EDIT (मई 2019) "बोवर को आखिरकार हटा दिया गया है । कहानी का अंत।" (h / t: @DanDascalescu, नीचे, pithy सारांश के लिए।)
और, जबकि यार्न अभी भी सक्रिय है , इसके लिए बहुत सारी गति npm पर वापस आ गई, जब उसने यार्न की कुछ प्रमुख विशेषताओं को अपनाया।
