Bower est mort, vive npm. Et Yarn. Et webpack.

Bower n’est plus le gestionnaire de dépendances privilégié des projets front-end. Bien que le projet open source soit toujours maintenu, ses créateurs ont décidé de le déprécier et recommandent de migrer vers d’autres solutions, à savoir Yarn et webpack.

Dans cet article, nous expliquons pourquoi Bower était autrefois un excellent outil, présentons six raisons pour lesquelles il n’est plus nécessaire et expliquons comment adopter des technologies plus récentes et plus performantes.

À quoi servait Bower ?

Bower est un gestionnaire de packages, comme npm. Il gère les frameworks, les bibliothèques, les ressources et les utilitaires, les installe et veille à ce qu’ils soient à jour.

Traditionnellement, de nombreux projets de développement web associaient npm et Bower. npm gérait les dépendances back-end, tandis que Bower gérait celles du front-end. En fait, il fallait d’abord utiliser npm pour installer Bower.

Le principal avantage de Bower par rapport à npm était son graphe de dépendances aplati. npm recherche les dépendances des packages et peut installer automatiquement des milliers de dépendances et de sous-dépendances, y compris plusieurs copies du même package. Comme vous pouvez l’imaginer, ce n’est pas idéal pour les projets front-end, car cela peut alourdir considérablement les ressources à charger.

Bower, en revanche, laissait à l’utilisateur le soin de gérer les dépendances. Par exemple, si un projet comportait de nombreuses bibliothèques dépendant de jQuery, l’utilisateur pouvait choisir la version de jQuery à installer et la définir comme dépendance pour les autres bibliothèques.

Même si les avantages de Bower étaient convaincants, d’autres outils les offrent désormais, notamment npm, Yarn et webpack. Bower présente également des inconvénients notables dont vous devez tenir compte.

Six raisons d’abandonner Bower et d’adopter un nouveau workflow

Voici les principales raisons d’abandonner Bower pour gérer les dépendances front-end.

1. Les créateurs de Bower l’ont déprécié

Après un long débat animé sur Github, les créateurs de Bower ont conclu que l’outil n’apportait pas de valeur à la pile de développement web actuelle et qu’il fallait y mettre fin. Le projet open source est toujours maintenu pour les utilisateurs existants, mais c’est une excellente raison de ne plus utiliser la plateforme.

2. Bower proposait un graphe de dépendances aplati, désormais disponible avec NPM et Yarn

npm 3 propose un graphe de dépendances aplati, tout en permettant de prendre en charge plusieurs versions d’un même package si nécessaire (ce que Bower ne peut pas faire). Pour les utilisateurs de Yarn, la commande yarn install --flat produit un résultat similaire à celui de Bower (consultez la documentation de la CLI Yarn).

3. Bower complexifie les choses et fait doublon, puisqu’il nécessite NPM

Bower nécessitait npm pour fonctionner. La question revenait donc souvent : « Pourquoi ajouter un autre gestionnaire de packages si j’utilise déjà npm ? »

Pour beaucoup, Bower permettait de séparer utilement les packages back-end et front-end. Mais il existe des moyens d’obtenir la même séparation avec npm, par exemple en créant deux dépôts. Bower semble donc redondant pour ceux qui utilisent déjà npm.

4. Bower possède un écosystème de packages distinct

Les développeurs de modules apprécient l’omniprésence de npm. Puisque tout le monde utilise npm, vous pouvez y publier votre dernier package et être sûr que vos utilisateurs y accéderont facilement. Jusqu’à récemment, toutefois, les développeurs de packages front-end devaient publier leur package à la fois sur npm et sur Bower, ce qui était moins pratique.

5. Bower faisait peser la gestion des dépendances sur l’utilisateur

L’un des principaux atouts de npm est qu’il installe automatiquement toutes les dépendances requises par les packages référencés dans votre code. C’est très pratique, mais cela ajoute aussi de la complexité et peut vous mener à une situation désastreuse appelée l’enfer des dépendances.

Bower ne proposait tout simplement pas cette fonctionnalité : les utilisateurs devaient définir minutieusement les dépendances requises par chaque package. Cela évitait les problèmes de dépendances, mais représentait beaucoup de travail manuel.

Grâce aux récentes avancées de npm et aux technologies associées comme webpack et Yarn, la gestion des dépendances en chaîne est bien plus simple.

6. Bower ne permet pas d’utiliser différentes versions d’un même package sur une même page

C’est un cas particulier, mais assez courant. Avec Bower, impossible de référencer la même bibliothèque dans deux packages différents en utilisant deux versions différentes. npm 3 permet de le faire nativement, tout en proposant un graphe de dépendances aplati.

Comment les packages sont-ils gérés aujourd’hui ?

Nous avons indiqué que les avantages de Bower avaient été dépassés par des outils plus récents. La pile de dépendances moderne, composée de npm/Yarn pour la gestion des packages Node et de webpack pour celle des ressources statiques, a rendu Bower superflu :

• npm est le gestionnaire de packages privilégié, pour les packages back-end comme front-end.

• Yarn est une interface pour npm qui offre plusieurs avantages importants : une installation des dépendances plus rapide, une meilleure capacité à verrouiller les packages ou à les « épingler » à une version précise, une sécurité renforcée et un mode hors ligne. Depuis la sortie de npm 3, certains de ces avantages sont moins marqués. Il vaut donc la peine d’évaluer attentivement la valeur ajoutée de Yarn dans votre workflow.

• webpack est un module bundler, autrement dit un outil de build. Il fournit des loaders et des plugins qui vous permettent de préparer les dépendances de fichiers statiques de vos projets web. Par exemple, webpack peut regrouper plusieurs fichiers CSS, les minifier et les intégrer à votre projet. webpack comble une lacune importante pour les utilisateurs de npm, car beaucoup des ressources utilisées pour créer une application web ne sont pas des composants Node.js. webpack peut récupérer, préparer et installer tous ces autres éléments, tandis que npm installe les bibliothèques Node utilisées par l’application web.

Il existe déjà d’excellentes ressources pour migrer de Bower vers une pile plus moderne et polyvalente, notamment le très bon article d’Anrejs Abrickis et l’article officiel d’Adam Stankiewicz, créateur de Bower.

Conclusion

Face au labyrinthe de bibliothèques et de frameworks front-end disponibles aujourd’hui, un gestionnaire de packages est indispensable pour gérer vos dépendances front-end.

Bower a joué un rôle important dans l’amélioration de la gestion des dépendances par les développeurs front-end. Les avantages qu’il offrait ont ouvert la voie à des fonctionnalités ultérieures de npm et Yarn. Mais Bower n’est plus la meilleure solution. L’arrivée de Yarn et les changements apportés à npm 3 vous permettent de profiter de tous les avantages de Bower sans les contraintes.

Migrer vers npm ou Yarn simplifiera considérablement votre processus de développement. Les outils actuels facilitent plus que jamais la gestion de la vaste gamme de composants front-end.