सवाल बोवर और एनपीएम के बीच क्या अंतर है?


बीच मौलिक अंतर क्या है bower तथा npm? बस कुछ सादा और सरल चाहते हैं। मैंने अपने कुछ सहयोगियों का उपयोग देखा है bower तथा npm उनकी परियोजनाओं में एक दूसरे के रूप में।


1612
2017-09-05 16:53


मूल


संबंधित उत्तर stackoverflow.com/a/21199026/1310070 - sachinjain024
के संभावित डुप्लिकेट जावास्क्रिप्ट निर्भरता प्रबंधन: एनपीएम बनाम बॉवर बनाम वोल्? - anotherdave
इस सवाल का जवाब पुराना लगता है। क्या कोई हमें बता सकता है कि 2016 में क्या करना है यदि हम एनपीएम 3 का उपयोग करते हैं जो फ्लैट निर्भरता का समर्थन करता है? एनएमपी 3 और बॉवर में क्या अंतर है और अभी सबसे अच्छा अभ्यास क्या है? - amdev
नीचे की रेखा, @amdev: बॉवर अब बहिष्कृत है। एनपीएम (या यार्न, जो केवल मामूली अंतर है) वह है जहां यह है। मुझे किसी व्यवहार्य विकल्प से अवगत नहीं है। - XML


जवाब:


सभी पैकेज प्रबंधकों के पास कई डाउनसाइड्स हैं। आपको सिर्फ यह चुनना है कि आप किसके साथ रह सकते हैं।

इतिहास

NPM node.js मॉड्यूल के प्रबंधन शुरू कर दिया (यही कारण है कि पैकेज में जाओ node_modules डिफ़ॉल्ट रूप से), लेकिन यह संयुक्त होने पर भी फ्रंट-एंड के लिए काम करता है Browserify या वेबपैक।

कुंज पूरी तरह से फ्रंट एंड के लिए बनाया गया है और इसे ध्यान में रखते हुए अनुकूलित किया गया है।

रेपो का आकार

एनपीएम बहुत अधिक है, बोवर से काफी बड़ा है, जिसमें सामान्य उद्देश्य जावास्क्रिप्ट (जैसे country-data देश की जानकारी के लिए या sorts फ़ंक्शंस को सॉर्ट करने के लिए जो फ्रंट एंड या बैक एंड पर प्रयोग योग्य है)।

बोवर में बहुत कम पैकेज हैं।

शैलियों का प्रबंधन आदि

बोवर शैलियों आदि शामिल हैं।

एनपीएम जावास्क्रिप्ट पर केंद्रित है। शैलियों को या तो अलग से डाउनलोड किया जाता है या कुछ ऐसा आवश्यक होता है npm-sass या sass-npm

निर्भरता हैंडलिंग

सबसे बड़ा अंतर यह है कि एनपीएम नेस्टेड निर्भरता करता है (लेकिन डिफ़ॉल्ट रूप से फ्लैट है) जबकि बोवर को एक फ्लैट निर्भरता पेड़ की आवश्यकता होती है (उपयोगकर्ता पर निर्भरता संकल्प का बोझ डालता है)

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

कुछ परियोजनाओं का उपयोग दोनों यह है कि वे बोवर का उपयोग फ्रंट एंड पैकेज और एनएमपी के लिए डेवलपर टूल्स जैसे यमन, ग्रंट, गुलप, जेएसहिंट, कॉफीस्क्रिप्ट इत्यादि के लिए करते हैं।


साधन


1828
2017-09-06 08:09



एक नेस्टेड निर्भरता पेड़ आगे के अंत में ऐसा क्यों नहीं करता है? - Lars Nyström
क्या फ्रंट-एंड एनपीएम पैकेज एक फ्लैट निर्भरता पेड़ भी नहीं हो सकता है? मुझे सामना करना पड़ रहा है "हमें 2 पैकेज प्रबंधकों की आवश्यकता क्यों है?" दुविधा। - Steven Vachon
"फ्लैट निर्भरता पेड़" से आपका क्या मतलब है? फ्लैट पेड़ क्या है - एक सूची? यह तब एक पेड़ नहीं है। - mvmn
असल में, एक रास्ता भी एक पेड़ है। यह सिर्फ एक विशेष मामला है। विकीपीडिया से: "गणित में, और अधिक विशेष रूप से ग्राफ सिद्धांत में, एक पेड़ एक अप्रत्यक्ष ग्राफ है जिसमें किसी भी दो कोष्ठक बिल्कुल एक पथ से जुड़े होते हैं।" - Jørgen Fogh
एनपीएम 3 अब एक फ्लैट निर्भरता पेड़ का समर्थन करता है। - vasa


यह उत्तर सिंधे सोरहस के जवाब के लिए एक अतिरिक्त है। एनपीएम और बोवर के बीच बड़ा अंतर यह है कि वे रिकर्सिव निर्भरताओं का इलाज करते हैं। ध्यान दें कि उन्हें एक ही परियोजना में एक साथ उपयोग किया जा सकता है।

पर एनपीएम अकसर किये गए सवाल: (6 सितंबर 2015 से archive.org लिंक)

घोंसले के बिना निर्भरता संघर्ष से बचना बहुत मुश्किल है   निर्भरता। एनएमपी काम करता है, और यह है कि यह मौलिक है   एक बेहद सफल दृष्टिकोण साबित हुआ।

पर कुंज होमपेज:

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

संक्षेप में, एनपीएम स्थिरता का लक्ष्य रखता है। बोवर का लक्ष्य न्यूनतम संसाधन भार के लिए है। यदि आप निर्भरता संरचना तैयार करते हैं, तो आप इसे देखेंगे:

NPM:

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

जैसा कि आप देख सकते हैं कि यह कुछ निर्भरताओं को दोबारा स्थापित करता है। निर्भरता ए में तीन स्थापित उदाहरण हैं!

बोवर:

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

यहां आप देखते हैं कि सभी अद्वितीय निर्भरताएं समान स्तर पर हैं।

तो, एनपीएम का उपयोग क्यों परेशान करते हैं?

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

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

एनपीएम 3 के लिए अद्यतन करें:

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

  • [Node_modules]
    • डे एक v1.0
    • डीपी बी v1.0
      • डे एक v1.0 (रूट संस्करण का उपयोग करता है)
    • डीपी सी v1.0
      • डी ए वी 2.0 (यह संस्करण रूट संस्करण से अलग है, इसलिए यह एक नेस्टेड इंस्टॉलेशन होगा)

अधिक जानकारी के लिए, मैं पढ़ने का सुझाव देता हूं एनपीएम 3 के दस्तावेज़


338
2017-11-24 13:10



यह अब लगभग एक झुकाव है कि "सॉफ्टवेयर विकास व्यापार-बंद के बारे में है।" यह एक अच्छा उदाहरण है। एक चुनना चाहिए भी के साथ अधिक स्थिरता npm  या न्यूनतम संसाधन लोड के साथ bower। - jfmercer
@ श्रेक मैं स्पष्ट रूप से कह रहा हूं कि आप वास्तव में दोनों का उपयोग कर सकते हैं। उनके पास अलग-अलग उद्देश्यों हैं, जैसा कि मैंने अंतिम पैराग्राफ में बताया है। यह मेरी आंखों में एक व्यापार बंद नहीं है। - Justus Romijn
आह, मैं देखता हूं कि मैंने आपको गलत समझा। या मैंने सावधानीपूर्वक पर्याप्त नहीं पढ़ा। स्पष्टीकरण के लिए धन्यवाद। :-) यह अच्छा है कि दोनों को व्यापार-बंद किए बिना इस्तेमाल किया जा सकता है। - jfmercer
@AlexAngas मैंने npm3 के लिए एक अद्यतन जोड़ा है। बोवर की तुलना में इसमें अभी भी कुछ प्रमुख अंतर हैं। एनपीएम शायद निर्भरता के कई संस्करणों का समर्थन करेगा, जबकि बोवर नहीं करता है। - Justus Romijn
एनपीएम 3 बोवर के करीब हो रहा है;) - ni3


टीएल; डीआर: रोजमर्रा के उपयोग में सबसे बड़ा अंतर घोंसला निर्भरता नहीं है ... यह मॉड्यूल और ग्लोबल्स के बीच अंतर है।

मुझे लगता है कि पिछले पोस्टर ने कुछ बुनियादी भेदों को अच्छी तरह से कवर किया है। (नेपस्टेड निर्भरताओं का एनपीएम का उपयोग बड़े, जटिल अनुप्रयोगों के प्रबंधन में वास्तव में बहुत उपयोगी है, हालांकि मुझे नहीं लगता कि यह सबसे महत्वपूर्ण भेद है।)

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

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

बोवर दृष्टिकोण: वैश्विक संसाधन, पसंद है <script> टैग

रूट पर, बोवर सादे-पुरानी स्क्रिप्ट फ़ाइलों को लोड करने के बारे में है। जो भी स्क्रिप्ट फाइलें हैं, बोवर उन्हें लोड करेगा। जिसका मूल रूप से मतलब है कि बोवर सादे-पुराने में आपकी सभी स्क्रिप्ट को शामिल करने जैसा है <script>में है <head> आपके एचटीएमएल का।

तो, आप जिस मूलभूत दृष्टिकोण का उपयोग करते हैं, लेकिन आपको कुछ अच्छी स्वचालन सुविधाएं मिलती हैं:

  • आपको अपने प्रोजेक्ट रेपो (विकास के दौरान) में जेएस निर्भरताओं को शामिल करने की आवश्यकता होती है, या उन्हें सीडीएन के माध्यम से प्राप्त करने की आवश्यकता होती है। अब, आप रेपो में उस अतिरिक्त डाउनलोड वजन को छोड़ सकते हैं, और कोई जल्दी कर सकता है bower installऔर तुरंत उन्हें क्या चाहिए, स्थानीय रूप से।
  • यदि कोई बोवर निर्भरता तब अपनी निर्भरताओं को निर्दिष्ट करती है bower.json, वे भी आपके लिए डाउनलोड किए जाएंगे।

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

एनपीएम दृष्टिकोण: सामान्य जेएस मॉड्यूल, स्पष्ट निर्भरता इंजेक्शन

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

स्मारक लोगों की तुलना में मैंने 'मॉड्यूल क्यों?' के सवाल का सामना किया है, लेकिन यहां एक कैप्सूल सारांश है:

  • मॉड्यूल के अंदर कुछ भी प्रभावी ढंग से है namespaced, जिसका अर्थ है कि यह अब वैश्विक वैरिएबल नहीं है, और आप इसके बिना आकस्मिक रूप से संदर्भित नहीं कर सकते हैं।
  • मॉड्यूल के अंदर कुछ भी जानबूझकर किसी विशेष संदर्भ (आमतौर पर एक और मॉड्यूल) में इंजेक्शन दिया जाना चाहिए ताकि इसका उपयोग किया जा सके
  • इसका मतलब है कि आपके आवेदन के विभिन्न हिस्सों में आप एक ही बाहरी निर्भरता (lodash, मान लें) के कई संस्करण हो सकते हैं, और वे टकराव / संघर्ष नहीं करेंगे। (यह आश्चर्यजनक रूप से अक्सर होता है, क्योंकि आपका स्वयं का कोड निर्भरता के एक संस्करण का उपयोग करना चाहता है, लेकिन आपकी बाहरी निर्भरताओं में से एक यह है कि संघर्षों को एक और निर्दिष्ट करता है। या आपके पास दो बाह्य निर्भरताएं हैं जो प्रत्येक एक अलग संस्करण चाहते हैं।)
  • चूंकि सभी निर्भरताओं को मैन्युअल रूप से किसी विशेष मॉड्यूल में इंजेक्शन दिया जाता है, इसलिए उनके बारे में तर्क करना बहुत आसान होता है। आप एक तथ्य के लिए जानते हैं: "इस पर काम करते समय मुझे केवल एक ही कोड पर विचार करने की आवश्यकता है जिसे मैंने जानबूझकर यहां इंजेक्ट करने के लिए चुना है"
  • क्योंकि इंजेक्शन मॉड्यूल की सामग्री भी है समझाया वैरिएबल के पीछे आप इसे असाइन करते हैं, और सभी कोड सीमित दायरे के अंदर निष्पादित होते हैं, आश्चर्य और टकराव बहुत असंभव हो जाते हैं। यह बहुत कम संभावना है कि आपकी निर्भरताओं में से किसी एक से गलती से ग्लोबल वैरिएबल को फिर से परिभाषित किए बिना, या आप ऐसा करेंगे। (यह कर सकते हैं ऐसा होता है, लेकिन आपको आमतौर पर ऐसा करने के लिए अपने रास्ते से बाहर जाना पड़ता है window.variable। एक दुर्घटना जो अभी भी होती है वह असाइन कर रही है this.variable, यह महसूस नहीं कर रहा है this वास्तव में है window वर्तमान संदर्भ में।)
  • जब आप किसी व्यक्तिगत मॉड्यूल का परीक्षण करना चाहते हैं, तो आप आसानी से जान सकते हैं: मॉड्यूल के अंदर चलने वाले कोड को वास्तव में और क्या (निर्भरता) प्रभावित कर रहा है? और, क्योंकि आप स्पष्ट रूप से सबकुछ इंजेक्शन कर रहे हैं, आप आसानी से उन निर्भरताओं का नकल कर सकते हैं।

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


कॉमनजेएस / नोड मॉड्यूल सिंटैक्स का उपयोग करने के तरीके को सीखने में केवल 30 सेकंड लगते हैं। किसी दिए गए जेएस फ़ाइल के अंदर, जो मॉड्यूल होने जा रहा है, आप पहले किसी भी बाहरी निर्भरताओं को घोषित करना चाहते हैं, जैसे आप:

var React = require('react');

फ़ाइल / मॉड्यूल के अंदर, आप जो कुछ भी करेंगे, वह करें और कुछ ऑब्जेक्ट या फ़ंक्शन बनाएं जो आप बाहरी उपयोगकर्ताओं को बेनकाब करना चाहते हैं, शायद इसे कॉल करना myModule

एक फ़ाइल के अंत में, आप जो कुछ भी दुनिया के साथ साझा करना चाहते हैं उसे निर्यात करते हैं, जैसे:

module.exports = myModule;

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

और, चूंकि ईएस 6 मॉड्यूल (जिसे आप संभवतया ईएस 5 को बैबेल या इसी तरह के साथ पारदर्शी कर देंगे) व्यापक स्वीकृति प्राप्त कर रहे हैं, और ब्राउज़र में या नोड 4.0 दोनों में काम करते हैं, हमें एक का उल्लेख करना चाहिए अच्छा अवलोकन उन लोगों में से भी।

मॉड्यूल के साथ काम करने के लिए पैटर्न के बारे में अधिक जानकारी यह डेक


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


256
2017-07-26 03:12



खुशी है कि यह जवाब यहां था, अन्य लोकप्रिय उत्तरों में इस विवरण का उल्लेख नहीं है। एनपीएम आपको मॉड्यूलर कोड लिखने के लिए मजबूर करता है। - Juan Mendes


2017-अक्टूबर अद्यतन

अंततः बोवर रहा है पदावनत। कहानी का अंत।

पुराना जवाब

मैटियास पेटटर जोहानसन से, स्पॉटिफी में जावास्क्रिप्ट डेवलपर:

लगभग सभी मामलों में, बोवर पर ब्राउज़रify और एनपीएम का उपयोग करना अधिक उचित है। यह बोवर की तुलना में फ्रंट एंड ऐप के लिए बस एक बेहतर पैकेजिंग समाधान है। Spotify पर, हम पूरे वेब मॉड्यूल (एचटीएमएल, सीएसएस, जेएस) पैकेज करने के लिए एनपीएम का उपयोग करते हैं और यह बहुत अच्छी तरह से काम करता है।

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

हमें बोवर का उपयोग करना बंद कर देना चाहिए और एनपीएम के आसपास समेकित होना चाहिए। शुक्र है, यही है घटित हो रहा है:

Module counts - bower vs. npm

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

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

(ध्यान दें कि Webpack तथा जमना अगस्त 2016 तक ब्राउजरिफ़ से बेहतर होने के लिए व्यापक रूप से माना जाता है।)


117
2017-07-04 10:48



वेबपैक और एनपीएम मुझे लगता है कि बेहतर है .. - refactor
<कटाक्ष> कृपया ध्यान रखें कि 'हैलो वर्ल्ड' एनपीएम परियोजना को 300+ मॉड्यूल चलाने की जरूरत है ... </ sarcasm>: O - Mariusz Jamro
मैं इस बात से सहमत नहीं हूं कि "बड़ी छोटी फाइलें" प्रदर्शन के लिए शानदार हैं, खासकर मोबाइल उपकरणों के लिए "। काफी विपरीत: प्रतिबंधित बैंडविड्थ को मांग पर लोड की गई छोटी फ़ाइलों की आवश्यकता होती है। - Michael Franzl
बहुत अच्छी सलाह नहीं है। अधिकांश एनपीएम पैकेज केवल नोडजेस बैकएंड होते हैं। यदि आप बैकएंड पर जावास्क्रिप्ट नहीं कर रहे हैं, या आपके पास मॉड्यूल सिस्टम नहीं है, तो पैकेज की संख्या अप्रासंगिक है क्योंकि बोवर आपकी आवश्यकताओं को बेहतर तरीके से फिट करेगा - Gerardo Grignoli
@GerardoGrignoli: बोवर इसके रास्ते पर है। - Dan Dascalescu


बोवर मॉड्यूल के एक संस्करण को बनाए रखता है, यह केवल आपके लिए सही / सर्वोत्तम चुनने में आपकी सहायता करने का प्रयास करता है।

जावास्क्रिप्ट निर्भरता प्रबंधन: एनपीएम बनाम बॉवर बनाम वोल्?

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


43
2017-07-19 20:59



मुझे लगता है कि सिंद्रे का उल्लेख है कि जब वह नेस्टेड निर्भरता के बारे में बात करता है। - Games Brainiac
@GamesBrainiac आपका सही, बस सोचा कि मैं इसे अपने शब्दों में रखूंगा। - Sagivf
@ सगीव ये हैं नहीं अपने स्वयं के शब्दों, जब तक कि आप भी ऐसे wheresrhys हैं जो मूल जवाब प्रदान किया यहाँ - dayuloli
@Sagivf कॉपी करने में कुछ भी गलत नहीं है ** प्रासंगिक भागों दूसरों के उत्तरों के अगर उन्होंने खुद को यहां कोई जवाब नहीं दिया है। यह सिर्फ मुझे थोड़ा सा गड़बड़ कर दिया तुमने कहा "बस सोचा कि मैं इसे अपने शब्दों में डाल दूंगा।" क्रेडिट जाना चाहिए जहां क्रेडिट देय है। - dayuloli
मुझे नहीं पता कि आपने इस जवाब पर लोगों को इतना क्यों चुना है। इस जवाब में वास्तव में नई जानकारी / परिप्रेक्ष्य है। - Calvin


मेरी टीम बोवर से दूर चली गई और एनपीएम में स्थानांतरित हो गई क्योंकि:

  • प्रोग्रामेटिक उपयोग दर्दनाक था
  • बोवर का इंटरफेस बदल रहा है
  • यूआरएल शॉर्टेंड की तरह कुछ विशेषताएं पूरी तरह टूटी हुई हैं
  • एक ही परियोजना में बोवर और एनपीएम दोनों का उपयोग दर्दनाक है
  • गिट टैग के साथ सिंक में bower.json संस्करण फ़ील्ड को रखना दर्दनाक है
  • स्रोत नियंत्रण! = पैकेज प्रबंधन
  • कॉमनजेएस समर्थन सीधा नहीं है

अधिक जानकारी के लिए, देखें "मेरी टीम बॉवर के बजाय एनपीएम का उपयोग क्यों करती है"


31
2018-02-16 21:04





इस उपयोगी स्पष्टीकरण से मिला http://ng-learn.org/2013/11/Bower-vs-npm/

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

दूसरी ओर बॉवर को आपकी फ्रंटेंड निर्भरताओं को प्रबंधित करने के लिए बनाया गया था। JQuery, AngularJS, अंडरस्कोर, आदि जैसे पुस्तकालय। एनपीएम के समान इसकी एक फ़ाइल है जिसमें आप bower.json नामक निर्भरताओं की एक सूची निर्दिष्ट कर सकते हैं। इस मामले में आपकी फ्रंटेंड निर्भरता बॉवर इंस्टॉल चलाकर स्थापित की जाती है जो डिफ़ॉल्ट रूप से उन्हें bower_components नामक फ़ोल्डर में इंस्टॉल करती है।

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


14
2017-10-03 00:08



के आगमन के साथ npm dedupe, यह थोड़ा पुराना है। देख मैटियास का जवाब। - Dan Dascalescu


Node.js के साथ काम करने वाले कई लोगों के लिए, बॉवर का एक बड़ा लाभ उन निर्भरताओं के प्रबंधन के लिए है जो जावास्क्रिप्ट नहीं हैं। यदि वे जावास्क्रिप्ट को संकलित करने वाली भाषाओं के साथ काम कर रहे हैं, तो एनपीएम का उपयोग उनकी कुछ निर्भरताओं को प्रबंधित करने के लिए किया जा सकता है। हालांकि, उनकी सभी निर्भरता नोड.जेएस मॉड्यूल नहीं होने जा रही हैं। जावास्क्रिप्ट में संकलित करने वालों में से कुछ में अजीब स्रोत भाषा विशिष्ट मैंगलिंग हो सकती है जो उपयोगकर्ताओं को स्रोत कोड की अपेक्षा करते समय जावास्क्रिप्ट को संकलित करने के लिए एक अचूक विकल्प प्रदान करता है।

एनपीएम पैकेज में सब कुछ उपयोगकर्ता के सामने जावास्क्रिप्ट होने की आवश्यकता नहीं है, लेकिन एनपीएम लाइब्रेरी पैकेज के लिए, कम से कम इसमें से कुछ होना चाहिए।


4
2017-10-11 20:42



यह npmjs ब्लॉग पोस्ट कहता है "आपके पैकेज में कुछ भी हो सकता है, भले ही यह ईएस 6, क्लाइंट-साइड जेएस, या यहां तक ​​कि एचटीएमएल और सीएसएस भी हो। ये चीजें हैं जो स्वाभाविक रूप से जावास्क्रिप्ट के साथ चालू होती हैं, इसलिए उन्हें वहां रखें।"। - Dan Dascalescu
बीच एक अंतर है हो सकता है, तथा शामिल करना चाहिए। बेशक वे कुछ भी शामिल कर सकते हैं, लेकिन सामान्य रूप से, वे शामिल करना चाहिए सामान्य जेएस के लिए कुछ प्रकार का इंटरफ़ेस। यह सब के बाद 'नोड पैकेज प्रबंधक' है। के बारे में हिस्सा ये चीजें हैं जो स्वाभाविक रूप से चालू होती हैं जावास्क्रिप्ट के साथ


बोवर और एनपीएम जावास्क्रिप्ट के लिए पैकेज प्रबंधक हैं।

कुंज

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

बोवर में bower.json नामक कॉन्फ़िगरेशन फ़ाइल होती है। इस फ़ाइल में हम बोवर के लिए कॉन्फ़िगरेशन को बनाए रख सकते हैं जैसे कि हमें किस निर्भरता की आवश्यकता है और लाइसेंस विवरण, विवरण, नाम आदि। बोवर फ्रंट-एंड पैकेज जैसे jquery, कोणीय, प्रतिक्रिया, एम्बर, नॉकआउट, रीढ़ की हड्डी आदि के लिए उपयुक्त है।

NPM

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

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

यह स्पष्ट रूप से फ्रंट एंड पर अच्छी तरह से काम नहीं करता है, क्योंकि हमें हमारी परियोजनाओं में jQuery की आवश्यकता है। हमें jQuery की केवल एक प्रति की आवश्यकता है, लेकिन जब किसी अन्य पैकेज को jQuery की आवश्यकता होती है, तो यह फिर से jQuery की एक और प्रति डाउनलोड करेगा। यह एनपीएम की मुख्य खामियों में से एक है।

मुख्य नोट: कई परियोजनाओं का उपयोग दोनों कारणों से है कि वे डेवलपर टूल के लिए फ्रंट एंड पैकेज और एनपीएम के लिए बोवर का उपयोग करते हैं। अपने प्रोजेक्ट में पैकेज मैनेजर को गुणा करना आपके वर्कफ़्लो को कठिन बना देता है। एनपीएम 3 के साथ मिलकर browserify या webpack अब जाने का रास्ता है।


1
2018-01-07 09:26