Question Quelle est la difference entre Bower et npm?


Quelle est la différence fondamentale entre bower et npm? Je veux juste quelque chose de simple et de simple. J'ai vu certains de mes collègues utiliser bower et npm de manière interchangeable dans leurs projets.


1611
2017-09-05 16:53


origine


Réponses:


Tous les gestionnaires de paquets ont de nombreux inconvénients. Vous devez juste choisir avec qui vous pouvez vivre.

Histoire

NPM a commencé à gérer les modules node.js (c'est pourquoi les paquets node_modules par défaut), mais il fonctionne aussi pour le frontal lorsqu'il est combiné avec Naviguer ou WebPack.

Tonnelle est créé uniquement pour le front-end et est optimisé dans cette optique.

Taille du repo

npm est beaucoup, beaucoup plus grand que bower, y compris JavaScript générique (comme country-data pour des informations sur le pays ou sorts pour les fonctions de tri utilisables à l'avant ou à l'arrière).

Bower a beaucoup moins de paquets.

Manipulation des styles etc

Bower inclut des styles etc.

npm est axé sur JavaScript. Les styles sont téléchargés séparément ou requis par quelque chose comme npm-sass ou sass-npm.

Gestion des dépendances

La plus grande différence est que npm fait des dépendances imbriquées (mais est plate par défaut) alors que Bower requiert un arbre de dépendance plat (met le fardeau de la résolution de dépendance sur l'utilisateur).

Un arbre de dépendance imbriqué signifie que vos dépendances peuvent avoir leurs propres dépendances qui peuvent avoir les leurs, et ainsi de suite. Cela permet à deux modules d'exiger différentes versions de la même dépendance et de continuer à travailler. Notez que depuis npm v3, l'arbre de dépendances sera à plat par défaut (gain d'espace) et ne s'emboîtera que si nécessaire, par exemple si deux dépendances ont besoin de leur propre version de Underscore.

Certains projets utilisent les deux, c'est qu'ils utilisent Bower pour les paquets frontaux et NPM pour les outils de développement comme Yeoman, Grunt, Gulp, JSHint, CoffeeScript, etc.


Ressources


1828
2017-09-06 08:09



Cette réponse est un ajout à la réponse de Sindre Sorhus. La différence majeure entre npm et Bower est la façon dont ils traitent les dépendances récursives. Notez qu'ils peuvent être utilisés ensemble dans un seul projet.

Sur le npm FAQ: (lien archive.org du 6 septembre 2015)

Il est beaucoup plus difficile d'éviter les conflits de dépendance sans imbrication   dépendances. Ceci est fondamental pour le fonctionnement de npm, et a   avérée être une approche extrêmement réussie.

Sur Tonnelle page d'accueil:

Bower est optimisé pour le front-end. Bower utilise une dépendance plate   arbre, ne nécessitant qu'une seule version pour chaque paquet, ce qui réduit la charge de la page   au minimum.

En bref, NPM vise la stabilité. Bower vise une charge minimale de ressources. Si vous dessinez la structure de dépendance, vous verrez ceci:

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

Comme vous pouvez le voir, il installe certaines dépendances de manière récursive. La dépendance A a trois instances installées!

Tonnelle:

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

Ici, vous voyez que toutes les dépendances uniques sont au même niveau.

Alors, pourquoi s'embêter à utiliser npm?

Peut-être que la dépendance B nécessite une version différente de la dépendance A par rapport à la dépendance C. npm installe les deux versions de cette dépendance pour que cela fonctionne de toute façon, mais Bower vous donnera un conflit parce qu'il n'aime pas la duplication (parce que le chargement de la même ressource sur une page Web est très inefficace et coûteux, il peut aussi donner des erreurs sérieuses). Vous devrez choisir manuellement la version que vous souhaitez installer. Cela peut avoir l'effet que l'une des dépendances va casser, mais c'est quelque chose que vous devrez corriger de toute façon.

Donc, l'utilisation courante est Bower pour les paquets que vous voulez publier sur vos pages Web (par ex. runtime, où vous évitez la duplication), et utilisez npm pour d'autres choses, comme tester, construire, optimiser, vérifier, etc. (p. temps de développement, où la duplication est moins préoccupante).

Mise à jour pour npm 3:

NPM 3 fait toujours les choses différemment par rapport à Bower. Il va installer les dépendances globalement, mais seulement pour la première version qu'il rencontre. Les autres versions sont installées dans l'arborescence (le module parent, puis node_modules).

  • [node_modules]
    • dep A v1.0
    • dep B v1.0
      • dep A v1.0 (utilise la version racine)
    • dep C v1.0
      • dep A v2.0 (cette version est différente de la version racine, ce sera donc une installation imbriquée)

Pour plus d'informations, je suggère de lire le docs de npm 3


338
2017-11-24 13:10



TL; DR: La plus grande différence dans l'utilisation quotidienne n'est pas les dépendances imbriquées ... c'est la différence entre les modules et les globals.

Je pense que les affiches précédentes ont bien couvert certaines des distinctions fondamentales. (L'utilisation de dépendances imbriquées par npm est en effet très utile pour la gestion de grandes applications complexes, bien que je ne pense pas que ce soit la distinction la plus importante.)

Je suis surpris, cependant, que personne n'ait explicitement expliqué l'une des distinctions les plus fondamentales entre Bower et npm. Si vous lisez les réponses ci-dessus, vous verrez le mot 'modules' souvent utilisé dans le contexte de npm. Mais c'est mentionné avec désinvolture, comme si cela pouvait même être juste une différence de syntaxe.

Mais cette distinction de modules vs. globals (ou modules vs 'scripts') est probablement la différence la plus importante entre Bower et npm. L'approche npm de tout mettre dans les modules vous oblige à changer la façon dont vous écrivez Javascript pour le navigateur, presque certainement pour le mieux.

L'approche de Bower: les ressources mondiales, comme <script> Mots clés

À la racine, Bower est sur le chargement de fichiers script anciens. Quels que soient ces fichiers de script, Bower les chargera. Ce qui signifie essentiellement que Bower est juste comme l'inclusion de tous vos scripts en plain-old <script>est dans le <head> de votre HTML.

Donc, même approche de base que vous avez l'habitude de, mais vous obtenez quelques bonnes commodités d'automatisation:

  • Vous aviez l'habitude d'inclure des dépendances JS dans votre rapport de projet (en cours de développement), ou de les obtenir via CDN. Maintenant, vous pouvez sauter ce poids de téléchargement supplémentaire dans le repo, et quelqu'un peut faire un rapide bower installet ont instantanément ce dont ils ont besoin, localement.
  • Si une dépendance de Bower spécifie ses propres dépendances dans son bower.json, ceux-ci seront téléchargés pour vous aussi.

Mais au-delà de ça, Bower ne change pas la façon dont nous écrivons javascript. Rien sur ce qui se passe dans les fichiers chargés par Bower ne doit changer du tout. En particulier, cela signifie que les ressources fournies dans les scripts chargés par Bower seront toujours (mais pas toujours) définies variables globales, disponible à partir de n'importe où dans le contexte d'exécution du navigateur.

L'approche NPM: Modules JS communs, injection de dépendances explicites

Tout le code dans Node land (et donc tout le code chargé via npm) est structuré en modules (en particulier, en tant que mise en œuvre de la Format du module CommonJS, ou maintenant, en tant que module ES6). Ainsi, si vous utilisez NPM pour gérer les dépendances côté navigateur (via Browserify ou autre chose qui fait le même travail), vous allez structurer votre code de la même manière que le fait Node.

Les gens plus intelligents que moi ont abordé la question de "Pourquoi les modules?", Mais voici un résumé de la capsule:

  • Tout ce qui est à l'intérieur d'un module est efficace namespaced, ce qui signifie que ce n'est plus une variable globale, et vous ne pouvez pas le référencer accidentellement sans le vouloir.
  • Tout ce qui se trouve à l'intérieur d'un module doit être intentionnellement injecté dans un contexte particulier (généralement un autre module) pour pouvoir l'utiliser
  • Cela signifie que vous pouvez avoir plusieurs versions de la même dépendance externe (lodash, disons) dans différentes parties de votre application, et elles ne vont pas entrer en conflit / conflit. (Cela arrive étonnamment souvent, car votre propre code veut utiliser une version d'une dépendance, mais l'une de vos dépendances externes spécifie une autre qui est en conflit ou vous avez deux dépendances externes qui veulent chacune une version différente.)
  • Comme toutes les dépendances sont injectées manuellement dans un module particulier, il est très facile de les raisonner. Vous savez pour un fait: "Le seul code dont je dois tenir compte lorsque je travaille sur ceci est ce que j'ai intentionnellement choisi d'injecter ici".
  • Parce que même le contenu des modules injectés est encapsulé derrière la variable que vous lui attribuez, et tout le code s'exécute dans une portée limitée, les surprises et les collisions deviennent très improbables. Il est beaucoup, beaucoup moins probable que quelque chose d'une de vos dépendances redéfinisse accidentellement une variable globale sans que vous vous en rendiez compte, ou que vous le fassiez. (Il pouvez arriver, mais vous devez généralement sortir de votre façon de le faire, avec quelque chose comme window.variable. Le seul accident qui a toujours tendance à se produire est l'attribution this.variable, ne réalisant pas que this est en fait window dans le contexte actuel.)
  • Lorsque vous voulez tester un module individuel, vous pouvez très facilement savoir: exactement quoi d'autre (dépendances) affecte le code qui s'exécute dans le module? Et, parce que vous injectez explicitement tout, vous pouvez facilement vous moquer de ces dépendances.

Pour moi, l'utilisation de modules pour le code frontal se résume à: travailler dans un contexte beaucoup plus étroit, plus facile à raisonner et à tester, et avoir une plus grande certitude sur ce qui se passe.


Il ne faut que 30 secondes pour apprendre à utiliser la syntaxe du module CommonJS / Node. Dans un fichier JS donné, qui va être un module, vous déclarez d'abord toutes les dépendances externes que vous voulez utiliser, comme ceci:

var React = require('react');

Dans le fichier / module, vous faites ce que vous voulez normalement, et créez un objet ou une fonction que vous voudrez exposer à des utilisateurs extérieurs, en l'appelant peut-être myModule.

A la fin d'un fichier, vous exportez ce que vous voulez partager avec le monde, comme ceci:

module.exports = myModule;

Ensuite, pour utiliser un flux de travail CommonJS dans le navigateur, vous utiliserez des outils tels que Browserify pour récupérer tous ces fichiers de modules individuels, encapsuler leur contenu lors de l'exécution et les injecter les uns dans les autres si nécessaire.

ET, puisque les modules ES6 (que vous allez probablement transmettre à ES5 avec Babel ou similaire) sont de plus en plus acceptés, et fonctionnent à la fois dans le navigateur ou dans le nœud 4.0, nous devrions mentionner bon aperçu de ceux aussi bien.

Plus sur les modèles pour travailler avec des modules dans ce deck.


EDIT (février 2017): Facebook's Fil est un remplacement / complément potentiel très important pour npm ces jours-ci: une gestion de paquets hors ligne, rapide et déterministe, basée sur ce que npm vous offre. Cela vaut la peine de regarder un projet JS, d'autant plus qu'il est si facile de l'échanger.


256
2017-07-26 03:12



Mise à jour 2017-Oct

Bower a finalement été déconseillé. Fin de l'histoire.

Plus ancienne réponse

De Mattias Petter Johansson, développeur JavaScript chez Spotify:

Dans presque tous les cas, il est plus approprié d'utiliser Browserify et npm sur Bower. C'est simplement une meilleure solution d'emballage pour les applications frontales que Bower. Chez Spotify, nous utilisons npm pour emballer des modules web entiers (html, css, js) et cela fonctionne très bien.

Bower se présente comme le gestionnaire de paquets pour le Web. Ce serait génial si cela était vrai - un gestionnaire de paquets qui rendait ma vie meilleure en tant que développeur front-end serait génial. Le problème est que Bower ne propose aucun outillage spécialisé à cet effet. Il n'offre aucun outil que je connaisse, mais pas spécialement pour les développeurs frontaux. Il n'y a simplement aucun avantage pour un développeur frontal à utiliser Bower par rapport à npm.

Nous devrions cesser d'utiliser bower et consolider autour de npm. Heureusement, c'est ce que est passe:

Module counts - bower vs. npm

Avec browserify ou webpack, il devient très facile de concaténer tous vos modules en gros fichiers minifiés, ce qui est génial pour les performances, en particulier pour les appareils mobiles. Ce n'est pas le cas avec Bower, qui nécessitera beaucoup plus de travail pour obtenir le même effet.

npm vous offre également la possibilité d'utiliser plusieurs versions de modules simultanément. Si vous n'avez pas fait beaucoup de développement d'applications, cela peut vous sembler une mauvaise chose au début, mais une fois que vous avez traversé quelques épisodes Dépendance Vous vous rendrez compte qu'ayant la possibilité d'avoir plusieurs versions d'un module est une très bonne fonctionnalité. Notez que NPM comprend un très pratique outil de déduplication cela fait automatiquement que vous n'utilisez que deux versions d'un module si vous avez réellement avoir à - si deux modules à la fois pouvez utiliser la même version d'un module, ils le feront. Mais s'ils ne peut pas, vous avez un très utile.

(Notez que Webpack et rollup sont largement considérés comme meilleurs que Browserify à partir d'août 2016.)


117
2017-07-04 10:48



Bower maintient une seule version des modules, il essaie seulement de vous aider à choisir le bon / meilleur pour vous.

Gestion des dépendances Javascript: npm vs bower vs volo?

Le NPM est meilleur pour les modules de nœuds car il existe un système de modules et vous travaillez localement. Bower est bon pour le navigateur car actuellement il n'y a que la portée globale, et vous voulez être très sélectif sur la version avec laquelle vous travaillez.


43
2017-07-19 20:59



Mon équipe s'est éloignée de Bower et a migré vers npm parce que:

  • L'usage programmatique était douloureux
  • L'interface de Bower changeait constamment
  • Certaines fonctionnalités, comme la raccourci url, sont entièrement cassées
  • Utiliser Bower et npm dans le même projet est douloureux
  • Garder le champ de version de bower.json synchronisé avec les balises git est douloureux
  • Contrôle de la source! = Gestion des paquets
  • Le support de CommonJS n'est pas simple

Pour plus de détails, voir "Pourquoi mon équipe utilise npm au lieu de bower".


31
2018-02-16 21:04



Trouvé cette explication utile de http://ng-learn.org/2013/11/Bower-vs-npm/

D'une part, npm a été créé pour installer les modules utilisés dans un environnement node.js, ou des outils de développement construits en utilisant node.js tels que Karma, lint, minifiers et ainsi de suite. npm peut installer des modules localement dans un projet (par défaut dans node_modules) ou globalement pour être utilisé par plusieurs projets. Dans les grands projets, la façon de spécifier les dépendances consiste à créer un fichier appelé package.json qui contient une liste de dépendances. Cette liste est reconnue par npm lorsque vous exécutez npm install, qui les télécharge et les installe pour vous.

D'autre part bower a été créé pour gérer vos dépendances frontend. Bibliothèques comme jQuery, AngularJS, underscore, etc. Similaire à npm, il a un fichier dans lequel vous pouvez spécifier une liste de dépendances appelée bower.json. Dans ce cas, vos dépendances frontend sont installées en exécutant bower install qui les installe par défaut dans un dossier appelé bower_components.

Comme vous pouvez le constater, bien qu'ils effectuent une tâche similaire, ils ciblent un ensemble de bibliothèques très différent.


14
2017-10-03 00:08



Pour beaucoup de personnes travaillant avec node.js, un avantage majeur de bower est de gérer les dépendances qui ne sont pas du tout javascript. S'ils travaillent avec des langages compilés en javascript, npm peut être utilisé pour gérer certaines de leurs dépendances. Cependant, toutes leurs dépendances ne seront pas des modules node.js. Certains de ceux qui se compilent en javascript peuvent avoir un bizarre mangling spécifique au langage source qui les rends compilés en javascript une option inélégante quand les utilisateurs attendent du code source.

Tout ce qui se trouve dans un paquetage npm ne doit pas nécessairement être un javascript pour l'utilisateur, mais pour les paquets de bibliothèque npm, au moins une partie devrait l'être.


4
2017-10-11 20:42