Est-ce que bower_components doit être gitignored?


157

Serait-il bon de ne conserver que le bower.jsonfichier et de gitignore tout le bower_componentsrépertoire?


Je viens de remarquer un livre de cuisine officiel de Symfony qui répond en fait à cette question exacte, en citant "Actuellement, vous devriez probablement valider les actifs téléchargés par Bower au lieu d'ajouter le répertoire à votre .gitignorefichier"
Pierre de LESPINAY

Réponses:


149

La page officielle de Bower déclarait:

NB Si vous ne créez pas un package destiné à être utilisé par d'autres (par exemple, vous créez une application Web), vous devez toujours vérifier les packages installés dans le contrôle de code source .

Assurez-vous de consulter le lien dans le devis, il traite de certains avantages et inconvénients. Le principal avantage qu'il mentionne est que leur archivage garantit que vos dépendances sont toujours disponibles, tant que votre référentiel est disponible. Peu importe ce qui arrive à Bower, GitHub ou tout ce qui serait nécessaire autrement.


1
Merci pour cet article intéressant. Donc pour l'instant nous n'avons toujours pas de "fichier verrouillé" équivalent à figer les versions.
Pierre de LESPINAY

1
@PierredeLESPINAY Uniquement pour le niveau supérieur. Ce qui manque, c'est un équivalent de la fonction d'emballage npm.
passy

3
Ils le disent également dans leur article de blog "En fin de compte, le choix de l'enregistrement ou non de tout votre répertoire / bower_components est à vous ...".
Krishnaraj

3
Le raisonnement derrière leur enregistrement est qu'un jour la bibliothèque pourrait disparaître d'Internet ou qu'il pourrait y avoir un certain temps d'arrêt qui à son tour pourrait provoquer des échecs de construction. En tant qu'utilisateur Maven / Gradle, je ne pense jamais à vérifier les dépendances.
Krishnaraj

7
Le conseil sur la page officielle de Bower pour vérifier les paquets installés dans le contrôle de code source a été supprimé en 2014: github.com/bower/bower.github.io/commit/…
utilisateur

52

Le fichier .gitignore dans un projet Yeoman AngularJS nouvellement généré a bower_components (et node_modules) répertoriés pour être ignorés (si vous ne connaissez pas Yeoman, c'est un outil de développement Web très réputé pour les applications Web modernes, donc c'est assez bien pour moi!):

.gitignore

node_modules
dist
.tmp
.sass-cache
bower_components

9

Il y a un temps et un lieu pour les deux approches. Pour Yeoman, il est approprié de s'appuyer sur bower.json car c'est un outil dans une chaîne d'outils et doit rester vivant et respirer avec l'écosystème du bower. Pour une application Web déployable, il est généralement recommandé de valider les dépendances et de conserver plus de contrôle.

Voici un bon article que j'aime bien qui en parle.


6

Si vous utilisez Grunt et Node avec Bower, il est logique de mettre bower_components dans votre .gitignore car lorsque vous exécutez grunt serve ou grunt build il prend en charge les dépendances pour vous, je suis sûr que c'est pourquoi dans Yeoman ils l'ajoutent à le .gitignore


5

Le générateur Yeoman a pré-rempli le .gitignore fichier avec bower_components, mais il a également été pré-rempli avec d'autres répertoires que je pense être nécessaires pour une application finale (comme www), j'ai donc fait quelques recherches.

J'ai découvert que www / index.html est une version réduite de l'app / index.html. Le répertoire de l'application et son contenu (y compris bower_components) contient les fichiers source nécessaires pour le répertoire de sortie (www). Vous livrez les répertoires source dans le contrôle de source (c'est-à-dire git) mais pas dans les fichiers générés (c'est-à-dire www). Les gestionnaires de paquets comme bower et npm sont destinés à être utilisés pendant la phase de construction / génération et leurs artefacts ne sont pas destinés à être archivés dans le contrôle de code source.

En fin de compte, la source que vous archivez dans git est la configuration minimale nécessaire pour créer le reste du projet à des fins de développement ou de déploiement.


0

Il est bon d'ignorer /bower_componentsdir et archiver uniquement bower.jsonet bower-locker.bower.jsonfichier si vous créez un fichier de verrouillage à l'aide de bower-locker écrit par Shawn Lonas .

Avant la création du bower-locker, il y avait un désavantage causé par un problème de bower n'ayant pas de capacité d'emballage rétractable mais il peut être atténué par la bibliothèque ci-dessus.

Exécutez les commandes suivantes pour y parvenir:

npm install bower-locker -g

ou

yarn global add bower-locker

puis générez le fichier de verrouillage basé sur le bower.jsonfichier existant en exécutant:

bower-locker lock

Le bower.jsonfichier d' origine sera renommé enbower-locker.bower.json

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.