javascript معنى - ما الفرق بين Bower و npm؟




meaning (9)

ما هو الفرق الأساسي بين كلاً من bower و npm ؟ فقط اريد شيئًا بسيطًا وبسيطًا. لقد رأيت بعض زملائي يستخدمون npm و npm بالتبادل في مشاريعهم.


Answers

TL ؛ DR: الاختلاف الأكبر في الاستخدام اليومي ليس تبعيات متداخلة ... إنه الفرق بين الوحدات والكرة الأرضية.

أعتقد أن الملصقات السابقة غطت بعض الفروقات الأساسية. (إن استخدام npm للاعتمادات المتداخلة مفيد للغاية في إدارة التطبيقات الكبيرة والمعقدة ، على الرغم من أنني لا أعتقد أن هذا هو التمييز الأكثر أهمية).

أنا مندهش ، ومع ذلك ، لا أحد قد أوضح صراحة واحدة من أهم الفوارق الأساسية بين Bower و npm. إذا كنت تقرأ الإجابات المذكورة أعلاه ، سترى كلمة "وحدات" المستخدمة في كثير من الأحيان في سياق npm. لكنه ذكر بشكل عرضي ، كما لو أنه قد يكون مجرد اختلاف في البنية.

ولكن هذا التمييز من الوحدات مقابل globals (أو وحدات مقابل "مخطوطات") هو على الأرجح الفرق الأكثر أهمية بين Bower و npm. يتطلب منك نهج npm في وضع كل شيء في الوحدات تغيير طريقة كتابة جافا سكريبت للمتصفح ، بالتأكيد إلى الأفضل.

The Bower Approach: Global Resources، Like <script> Tags

في الجذر ، Bower حول تحميل ملفات البرامج النصية القديمة. مهما كانت ملفات البرامج النصية هذه تحتوي على Bower ، سيتم تحميلها. وهو ما يعني بالضرورة أن Bower يشبه تمامًا جميع النصوص البرمجية الموجودة في <script> القديمة في <head> في HTML.

لذلك ، نفس النهج الأساسي الذي اعتدت عليه ، ولكنك تحصل على بعض وسائل الراحة الآلية الجميلة:

  • كنت في حاجة إلى تضمين تبعيات JS في repo مشروعك (أثناء تطوير) ، أو الحصول عليها عبر CDN. الآن ، يمكنك تخطي وزن التنزيل الإضافي هذا في الريبو ، ويمكن لأي شخص القيام bower install السريع bower install على الفور ما يحتاجه ، محليًا.
  • إذا كانت تبعية Bower تحدد التبعيات الخاصة بها في bower.json ، فسيتم تنزيلها لك أيضًا.

ولكن أبعد من ذلك ، لا يغير Bower كيف نكتب javascript . لا شيء على ما يدور داخل الملفات التي تم تحميلها من قبل Bower يحتاج إلى تغيير على الإطلاق. وبشكل خاص ، يعني هذا أن الموارد المتوفرة في البرامج النصية التي تم تحميلها بواسطة Bower (عادة ، ولكن ليس دائمًا) ما زالت تُعرّف كمتغيرات عمومية ، متوفرة من أي مكان في سياق تنفيذ المتصفح.

نهج npm: وحدات شبيبة المشتركة ، وحقن التبعية الصريحة

يتم تنظيم كافة التعليمات البرمجية في عقدة الأرض (وبالتالي يتم تحميل كافة التعليمات البرمجية عبر npm) كوحدات (بشكل خاص ، كتطبيق لتنسيق وحدة CommonJS ، أو الآن ، كوحدة ES6). لذلك ، إذا كنت تستخدم الآلية الوقائية الوطنية للتعامل مع تبعيات جانب المتصفح (عبر Browserify أو أي شيء آخر يقوم بنفس الوظيفة) ، فسوف تقوم ببناء كودك بنفس الطريقة التي تقوم بها العقدة.

أكثر ذكاءً من أن أتعامل مع سؤال "لماذا الوحدات؟" ، لكن إليكم ملخص الكبسولة:

  • أي شيء داخل الوحدة النمطية يتم تسميته بفعالية ، وهذا يعني أنه ليس متغيرًا عالميًا أكثر من ذلك ، ولا يمكنك الرجوع إليه بدون قصد دون الحاجة إلى ذلك.
  • يجب حقن أي شيء داخل وحدة ما عن قصد في سياق معين (عادة وحدة أخرى) من أجل الاستفادة منه
  • هذا يعني أنه يمكن أن يكون لديك إصدارات متعددة لنفس التبعية الخارجية (دعنا ، دعنا نقول) في أجزاء مختلفة من التطبيق الخاص بك ، ولن تتصادم / تتعارض. (يحدث هذا بشكل مفاجئ في كثير من الأحيان ، لأن رمزك الخاص يريد استخدام إصدار واحد من التبعية ، لكن أحد التبعيات الخارجية يحدد آخر التعارضات. أو لديك تبعيتين خارجيتين يرغب كل منهما في إصدار مختلف.)
  • نظرًا لأن جميع التبعيات يتم حقنها يدويًا في وحدة معينة ، فمن السهل جدًا التفكير فيها. أنت تعرف حقيقة: "إن الشفرة الوحيدة التي يجب مراعاتها عند العمل على هذا هو ما اخترته عن قصد لحقن هنا" .
  • لأنه حتى محتوى الوحدات المحقونة يتم تغليفه خلف المتغير الذي قمت بتعيينه إليه ، وكل التعليمات البرمجية تنفذ داخل نطاق محدود ، فإن المفاجآت والتصادمات تصبح غير محتملة. من المحتمل أن يكون شيئًا ما من أحد الاعتماديات سيعيد تعريف متغير عالمي دون أن تدركه ، أو أنك ستفعل ذلك. ( يمكن أن يحدث ذلك ، لكنك عادة ما يجب أن تخرج من طريقك للقيام بذلك ، مع شيء مثل window.variable . الحادث الوحيد الذي لا يزال يميل إلى الحدوث هو تعيين هذا this.variable ، وليس إدراك أن this هو في الواقع window في التيار سياق الكلام.)
  • عندما تريد اختبار وحدة نمطية فردية ، يمكنك بسهولة معرفة ما يلي: بالضبط ما الذي يؤثر على التعليمات البرمجية الأخرى التي تعمل داخل الوحدة؟ ولأنك تقوم بحقن كل شيء بشكل صريح ، يمكنك بسهولة أن تسخر من تلك التبعيات.

بالنسبة لي ، يتحول استخدام وحدات التعليمات البرمجية للواجهة الأمامية إلى: العمل في سياق أضيق كثيرًا من السهل التفكير فيه واختباره ، والحصول على قدر أكبر من اليقين بشأن ما يحدث.

يستغرق حوالي 30 ثانية فقط لمعرفة كيفية استخدام بناء جملة الوحدة النمطية CommonJS / عقدة. داخل ملف JS معين ، والذي سيكون وحدة نمطية ، يجب عليك أولاً إعلان أي تبعيات خارجية ترغب في استخدامها ، مثل:

var React = require('react');

داخل الملف / الوحدة النمطية ، يمكنك القيام بكل ما تفعله في المعتاد ، وإنشاء كائن أو وظيفة تريد myModule لمستخدمين خارجيين ، وقد يطلق عليها ربما myModule .

في نهاية الملف ، يمكنك تصدير كل ما تريد مشاركته مع العالم ، كما يلي:

module.exports = myModule;

بعد ذلك ، لاستخدام سير عمل يستند إلى CommonJS في المستعرض ، ستستخدم أدوات مثل Browserify للاستيلاء على جميع ملفات الوحدة النمطية الفردية ، وتغليف محتوياتها في وقت التشغيل ، وحقنها في بعضها البعض حسب الحاجة.

وحيث إن وحدات ES6 (التي سترجح على الأرجح إلى ES5 مع بابل أو ما شابه) تكتسب قبولًا واسعًا ، وتعمل في المتصفح أو في Node 4.0 ، يجب أن نذكر نظرة عامة جيدة أيضًا.

المزيد حول أنماط العمل مع الوحدات النمطية في هذا السطح .

EDIT (فبراير 2017): يعتبر غزل الفيس بوك بديلاً هامًا / بديلًا محتملاً للـ npm في هذه الأيام: إدارة سريعة ، حتمية ، دون اتصال بالإنترنت ، تعتمد على ما تقدمه لك npm. إنه يستحق البحث عن أي مشروع JS ، خاصة أنه من السهل تبديله داخل / خارج.


2017-أكتوبر التحديث

أوقف Bower أخيرًا. نهاية القصة.

إجابة قديمة

من Mattias Petter Johansson ، مطور جافا سكريبت في Spotify :

في معظم الحالات تقريبًا ، من الأفضل استخدام Browserify و npm على Bower. إنه ببساطة حل تغليف أفضل للتطبيقات الأمامية من Bower هو. في Spotify ، نستخدم npm لحزم وحدات الويب بالكامل (html و css و js) وتعمل بشكل جيد.

العلامات التجارية Bower نفسها كمدير الحزم للويب. سيكون رائعا إذا كان هذا صحيحا - مدير مجموعة الذي جعل حياتي أفضل كمطور أمامي سيكون رائعا. المشكلة هي أن Bower لا تقدم أدوات متخصصة لهذا الغرض. إنه لا يقدم أي أدوات أعلم أن npm لا ، ولا سيما تلك التي تكون مفيدة بشكل خاص لمطوري الواجهة الأمامية. هناك ببساطة أي فائدة لمطوّر الواجهة الأمامية لاستخدام Bower عبر npm.

يجب أن نتوقف عن استخدام bower ودمج حول npm. لحسن الحظ ، هذا ما يحدث :

مع browserify أو webpack ، يصبح من السهل جدًا تجميع جميع وحداتك في ملفات كبيرة الحجم ، وهو أمر رائع للأداء ، خاصة للأجهزة المحمولة. ليس الأمر كذلك مع باور ، التي تتطلب عملاً أكبر بكثير للحصول على نفس التأثير.

يوفر لك npm أيضًا القدرة على استخدام إصدارات متعددة من الوحدات في وقت واحد. إذا لم تكن قد قمت بإجراء الكثير من تطوير التطبيقات ، فقد يضر هذا الأمر في البداية بأنه أمر سيئ ، ولكن بمجرد أن تمر بنوبات قليلة من جحيم التبعية سوف تدرك أن امتلاكك للقدرة على الحصول على إصدارات متعددة من وحدة واحدة هو رتق جميل ميزة رائعة. لاحظ أن npm يحتوي على أداة dedupe مفيدة للغاية والتي تعمل تلقائيًا على التأكد من أنك تستخدم فقط إصدارين من وحدة نمطية إذا كان عليك فعلاً - إذا كان بإمكان وحدتين كلاهما استخدام نفس الإصدار من وحدة نمطية واحدة ، فسوف يفعل ذلك. ولكن إذا لم يتمكنوا من ذلك ، فأنت في متناول اليد.

(لاحظ أن Webpack و Webpack يعتبران على نطاق واسع أفضل من Browserify اعتبارًا من أغسطس 2016).


بالنسبة للعديد من الأشخاص الذين يعملون مع node.js ، فإن الفائدة الرئيسية للكوخ هي إدارة التبعيات غير javascript على الإطلاق. إذا كانوا يعملون مع اللغات التي تتحول إلى javascript ، فيمكن استخدام آلية npm لإدارة بعض تبعياتهم. ومع ذلك ، لن تكون كافة التبعيات الخاصة بهم وحدات node.js. قد يكون لبعض من تلك التي تم تجميعها إلى javascript غموض خاص بلغة المصدر المصدر ، مما يجعل تمريرها حول تجميعها إلى javascript خيارًا غير لائق عندما يتوقع المستخدمون شفرة المصدر.

لا يحتاج كل شيء في حزمة npm إلى javascript مقابل المستخدم ، ولكن بالنسبة لحزم مكتبة npm ، يجب أن يكون بعضها على الأقل.


Bower و Npm هما مديري حزم لـ javascript.

كوخ ريفي

تم إنشاء Bower فقط من أجل تطوير الواجهة الأمامية. تستخدم شجرة التبعية المسطحة ، التي تتطلب إصدارًا واحدًا فقط لكل حزمة ، مما يقلل من تحميل الصفحة. ويهدف أساسا إلى الحد الأدنى من تحميل الموارد. لديها أقل من المساهمين ، وبالتالي فإن عملية التنمية بطيئة.

لدى Bower ملف تكوين يسمى bower.json. في هذا الملف ، يمكننا الحفاظ على تهيئة Bower مثل أي تبعيات نحتاجها وتفاصيل التراخيص والوصف والاسم وغير ذلك. Bower مناسب للحزم الأمامية مثل jquery ، الزاوي ، التفاعل ، العض ، الضربة القاضية ، العمود الفقري وهكذا.

الآلية الوقائية الوطنية

Npm هو الأكثر استخدامًا لإدارة وحدات Node.js ، ولكنه يعمل أيضًا للواجهة الأمامية. يستخدم شجرة تبعية متداخلة وكذلك شجرة تبعية flat. أنها تحظى بشعبية ولديها الكثير من المساهمين. لذا فإن الإصدار الجديد الخاص بها يأتي دائمًا بميزات مثيرة.

يحتوي Npm على ملف تكوين يسمى package.json. في هذا الملف ، يمكننا الحفاظ على تهيئة Npm مثل أي تبعيات نحتاجها وتفاصيل التراخيص والوصف والاسم وغير ذلك. يوفر Npm التبعيات و DevDependencies. ستقوم التبعيات بتنزيل الملفات الأمامية وحفظها مثل Jquery و Angular وما إلى ذلك. سيقوم DevDependencies بتنزيل أدوات التطوير والمحافظة عليها مثل Grunt و Gulp و JSHint وما إلى ذلك.

ومن الواضح أن هذا لا يعمل بشكل جيد في الواجهة الأمامية ، لأننا بحاجة إلى مسج في مشاريعنا. نحن بحاجة إلى نسخة واحدة فقط من jQuery ، ولكن عندما تتطلب حزمة أخرى jQuery ، فستقوم بتنزيل نسخة أخرى من jQuery مرة أخرى. هذا هو أحد العيوب الرئيسية للـ Npm.

ملاحظة أساسية: السبب وراء استخدام العديد من المشروعات هو استخدام Bower للحزم الأمامية و Npm لأدوات المطورين. إن مضاعفة إدارة الحزم في مشروعك تجعل عملك أكثر صعوبة. Npm 3 مقترن Browserify أو webpack هو الطريق للذهاب الآن.


ابتعد فريقي عن Bower وتم ترحيله إلى npm بسبب:

  • كان الاستخدام المبرمج مؤلمًا
  • ظلت واجهة Bower تتغير
  • بعض الميزات ، مثل الاختزال url ، يتم كسرها بالكامل
  • يعد استخدام Bower و npm في نفس المشروع أمرًا مؤلمًا
  • الحفاظ على حقل bower.json نسخة متزامنة مع علامات git مؤلمة
  • التحكم في المصدر! = إدارة الحزمة
  • دعم CommonJS ليست واضحة

لمزيد من التفاصيل ، راجع "لماذا يستخدم فريقي npm بدلاً من bower" .


npm هو الأكثر استخدامًا لإدارة الوحدات النمطية Node.js ، ولكنه يعمل أيضًا للواجهة الأمامية عند دمجه مع Browserify و / أو $ npm dedupe .

يتم إنشاء Bower فقط للواجهة الأمامية ويتم تحسينه مع وضع ذلك في الاعتبار. الاختلاف الأكبر هو أن npm تقوم بعمل شجرة تبعية متداخلة (حجم ثقيل) بينما يتطلب Bower شجرة تبعية مسطحة (تضع عبء دقة التبعية على المستخدم) .

تعني شجرة التبعية المتداخلة أن التبعيات الخاصة بك يمكن أن يكون لها تبعيات خاصة بها والتي يمكن أن يكون لها تبعية خاصة بها ، وهكذا. هذا رائع حقًا على الخادم حيث لا يتعين عليك الاهتمام كثيرًا بالفضاء والوقت. فهو لا يسمح لك بالاهتمام بصراعات التبعية حيث أن جميع الاعتمادات الخاصة بك تستخدم على سبيل المثال إصدارها الخاص من Underscore. من الواضح أن هذا لا يعمل جيدًا في الواجهة الأمامية. تخيل موقعًا يلزمه تنزيل ثلاث نسخ من jQuery.

السبب وراء استخدام العديد من المشاريع كلاهما هو استخدام Bower للحزم الأمامية و npm لأدوات المطور مثل Yeoman و Grunt و Gulp و JSHint و CoffeeScript وغيرها.

جميع مديري الحزم لديهم العديد من السلبيات. عليك فقط اختيار ما يمكنك العيش معه.

مصادر


تم العثور على هذا التفسير المفيد من http://ng-learn.org/2013/11/Bower-vs-npm/

من جهة ، تم إنشاء npm لتثبيت الوحدات النمطية المستخدمة في بيئة node.js ، أو أدوات التطوير التي تم إنشاؤها باستخدام node.js مثل Karma و lint و minifiers وما إلى ذلك. يمكن لـ npm تثبيت وحدات نمطية محليًا في مشروع (افتراضيًا في node_modules) أو عالميًا لاستخدامه بواسطة عدة مشاريع. في المشاريع الكبيرة ، طريقة تحديد التبعيات هي عن طريق إنشاء ملف يسمى package.json يحتوي على قائمة من التبعيات. يتم التعرف على تلك القائمة من قبل npm عند تشغيل تثبيت npm ، والذي يقوم بعد ذلك بتنزيلها وتثبيتها نيابةً عنك.

على الجانب الآخر ، تم إنشاء كوخ Bower لإدارة تبعيات الواجهة الأمامية الخاصة بك. المكتبات مثل jQuery و AngularJS وشرطة سفلية وما إلى ذلك. على غرار npm ، يوجد ملف يمكنك فيه تحديد قائمة من التبعيات تسمى bower.json. في هذه الحالة ، يتم تثبيت تبعيات الواجهة الأمامية الخاصة بك عن طريق تشغيل تثبيت bower الذي يقوم بتثبيتها في مجلد يسمى bower_components.

كما ترون ، على الرغم من قيامهم بأداء مهمة مماثلة ، فإنهم يستهدفون مجموعة مختلفة جدًا من المكتبات.


يحتفظ Bower بنسخة واحدة من الوحدات النمطية ، ولكنه يحاول مساعدتك فقط في اختيار أفضل واحد صحيح.

إدارة التبعية لجافا سكريبت: npm vs bower vs volo؟

NPM هو أفضل لوحدات العقدة لأن هناك نظام وحدة وكنت تعمل محليا. يعتبر Bower جيدًا للمتصفح نظرًا لأنه لا يوجد حاليًا إلا النطاق العالمي ، وتريد أن تكون انتقائيًا للغاية حول الإصدار الذي تعمل به.


ربما كنت قد رأيت التيلدا (~) و caret (^) في package.json. ما الفرق بينهم؟

عندما تقوم بتثبيت لحظة npm - حفظ ، فإنه يحفظ الإدخال في package.json مع البادئة (^) علامة الإقحام.

التلدة (~)

في أبسط العبارات ، تتطابق التيلدا (~) مع الإصدار الثانوي الأخير (الرقم الأوسط). ~ 1.2.3 سوف تطابق جميع إصدارات 1.2.x ولكن سوف يغيب 1.3.0.

علامة الإقحام (^)

حرف الإقحام (^) ، على الجانب الآخر ، أكثر استرخاء. ستقوم بتحديث لك إلى الإصدار الرئيسي الأحدث (الرقم الأول). ^ 1.2.3 سوف يتطابق مع أي إصدار 1.xx بما في ذلك 1.3.0 ، ولكنه سيصمد عند 2.0.0.

المرجع: https://medium.com/@Hardy2151/caret-and-tilde-in-package-json-57f1cbbe347b







javascript npm bower