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"
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.
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!):
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.
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
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.
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
.gitignore
fichier"Réponses:
La page officielle de Bower déclarait:
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.
la source
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
la source
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.
la source
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
la source
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.
la source
Il est bon d'ignorer
/bower_components
dir et archiver uniquementbower.json
etbower-locker.bower.json
fichier 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:
ou
puis générez le fichier de verrouillage basé sur le
bower.json
fichier existant en exécutant:Le
bower.json
fichier d' origine sera renommé enbower-locker.bower.json
la source