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 globaux.
Je pense que les affiches précédentes ont bien couvert certaines des distinctions de base. (L'utilisation par npm des dépendances imbriquées est en effet très utile dans la gestion d'applications volumineuses et 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 il est mentionné avec désinvolture, comme s'il pouvait même ne s'agir que d'une différence de syntaxe.
Mais cette distinction entre modules et globaux (ou modules vs 'scripts') est probablement la différence la plus importante entre Bower et npm. L'approche npm de tout mettre en modules vous oblige à changer la façon dont vous écrivez Javascript pour le navigateur, presque certainement pour le mieux.
The Bower Approach: Global Resources, Like <script>Tags
À la racine, Bower consiste à charger des fichiers de script anciens. Quels que soient ces fichiers de script, Bower les chargera. Ce qui signifie fondamentalement que Bower revient à inclure tous vos scripts dans les anciens <script>dans le <head>code HTML.
Donc, même approche de base à laquelle vous êtes habitué, mais vous obtenez de belles commodités d'automatisation:
- Auparavant, vous deviez inclure des dépendances JS dans le référentiel de votre projet (pendant le développement) ou les obtenir via CDN. Maintenant, vous pouvez ignorer ce poids de téléchargement supplémentaire dans le référentiel, et quelqu'un peut faire rapidement
bower installet instantanément ce dont il a besoin, localement.
- Si une dépendance Bower spécifie alors ses propres dépendances dans celles-ci
bower.json, celles-ci seront également téléchargées pour vous.
Mais au-delà de cela, Bower ne change pas la façon dont nous écrivons javascript . Rien sur ce qui se trouve à l'intérieur des fichiers chargés par Bower n'a besoin de changer du tout. En particulier, cela signifie que les ressources fournies dans les scripts chargés par Bower seront (généralement, mais pas toujours) toujours définies comme des variables globales , disponibles de n'importe où dans le contexte d'exécution du navigateur.
L'approche npm: modules JS communs, injection de dépendance explicite
Tout le code dans Node Land (et donc tout le code chargé via npm) est structuré en modules (en particulier, en tant qu'implémentation du format de module CommonJS , ou maintenant en tant que module ES6). Donc, 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 structurerez votre code de la même manière que Node.
Des gens plus intelligents que moi ont abordé la question «Pourquoi les modules?», Mais voici un résumé de la capsule:
- Tout ce qui se trouve à l'intérieur d'un module est effectivement à espace de noms , 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) afin de pouvoir l'utiliser.
- Cela signifie que vous pouvez avoir plusieurs versions de la même dépendance externe (lodash, disons) dans diverses parties de votre application, et elles ne se heurteront pas / n'entreront pas en conflit. (Cela se produit souvent de manière surprenante, 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.)
- Parce que 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 que je dois considérer lorsque je travaille sur ce point 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 à laquelle vous l'assignez et que 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 de l'une de vos dépendances redéfinisse accidentellement une variable globale sans que vous vous en rendiez compte, ou que vous le fassiez. (Cela peut arriver, mais vous devez généralement faire tout votre possible pour le faire, avec quelque chose comme
window.variable. Le seul accident qui a toujours tendance à se produire est l'attribution this.variable, sans se rendre compte que thisc'est en fait windowdans le contexte actuel.)
- Lorsque vous souhaitez tester un module individuel, vous pouvez très facilement savoir: exactement quoi d'autre (dépendances) affecte le code qui s'exécute à l'intérieur du module? Et, comme vous injectez tout explicitement, 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 environ 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 extérieures que vous souhaitez utiliser, comme ceci:
var React = require('react');
À l'intérieur du fichier / module, vous faites ce que vous feriez normalement et créez un objet ou une fonction que vous voudrez exposer à des utilisateurs extérieurs, en l'appelant peut-être myModule.
À la fin d'un fichier, vous exportez tout ce que vous voulez partager avec le monde, comme ceci:
module.exports = myModule;
Ensuite, pour utiliser un flux de travail basé sur CommonJS dans le navigateur, vous utiliserez des outils comme Browserify pour saisir tous ces fichiers de module individuels, encapsuler leur contenu au moment de l'exécution et les injecter les uns dans les autres selon les besoins.
ET, étant donné que les modules ES6 (que vous transposerez probablement vers ES5 avec Babel ou similaire) sont de plus en plus acceptés et fonctionnent à la fois dans le navigateur ou dans Node 4.0, nous devons également en mentionner un bon aperçu .
En savoir plus sur les modèles de travail avec les modules dans ce deck .
EDIT (février 2017): Facebook's Yarn est un remplacement / supplément potentiel très important pour npm ces jours-ci: une gestion de paquets rapide, déterministe et hors ligne qui s'appuie sur ce que npm vous offre. Cela vaut la peine de regarder n'importe quel projet JS, d'autant plus qu'il est si facile de l'échanger.
EDIT (mai 2019) "Bower a finalement été déconseillé . Fin de l'histoire." (h / t: @DanDascalescu, ci-dessous, pour un résumé concis.)
Et, alors que Yarn est toujours actif , une grande partie de l'élan pour le retour à npm une fois qu'il a adopté certaines des fonctionnalités clés de Yarn.
