Bower pour gérer les dépendances du thème de mon blog

Grunt & Bower

C’est à la lecture de cet excellent article de Raphaël Goetter (dont le livre « CSS avancées vers HTML5 et CSS3 » fut un de mes livres de chevet) sur Alsacreations que j’ai décidé de mettre en place Bower pour gérer les dépendances du thème de mon blog.

Pour ceux qui ne connaissent pas (encore) Bower et qui n’ont pas eu la curiosité de cliquer sur les liens ci-dessus: sachez juste que Bower est un gestionnaire de paquets pour le web (JS, CSS, etc). On pourrait même faire le raccourci en disant que Bower est au web ce que Composer est à PHP.

Les avantages immédiats que j’y trouve :

  • Un simple bower update et je mets à jour toutes les librairies tierces.
  • Le cloisonnement entre mon code et le code tiers. En effet, ce dernier se trouve dans un répertoire séparé: vendor (les habitudes de symfony2 ;-)).
  • Comme au travail je fais beaucoup de Symfony2 et d’eZ Publish 5, j’utilise pas mal composer, avec Bower je ne suis donc pas perdu.

Les inconvénients que j’y trouve :

  • Bower ne fait que récupérer les dépendances. Il ne permet pas (encore), comme (entre autre) Composer, de lancer des scripts post-installation ou post-mise-à-jour.
  • Bower récupère Bootstrap dans son intégralité alors que moi, j’aimerais l’optimiser et en réduire le poids.

Avant de pouvoir passer en production cette nouvelle version de mon blog, qui se doit d’être ISO avec la précédente, il me reste donc à régler quelques problèmes :

  • Optimiser ou reconstruire Bootstrap après l’avoir récupéré.
  • Minifier tout mon code.
  • Réfléchir à comment le pousser en production.
    En effet, Bower tournant sous node.js, je n’ai pas spécialement envie de déployer node sur mon serveur. Jusqu’à présent j’utilisais GIT pour déployer le code source et je lançais juste un script shell pour minifier CSS et JS via YUI Compressor. Là je pense que je vais, soit devoir héberger les scripts minifiés sur GIT (ce qui n’est pas une bonne pratique) soit mettre en place un Jenkins (pour la construction du paquet) et un Capistrano (pour le déploiement). Autant au boulot le couple Jenkins/Capistrano m’est indispensable autant là pour déployer une fois de temps en temps une nouvelle version de mon blog, je pense que je vais opter pour les fichiers dans GIT.

Pour ceux que ça intéressent, ma configuration Bower(.bowerrc & bower.json):

{
  "directory": "vendor"
}
{
    "name": "Boldy",
    "version": "1.1",
    "main": [
        "css/screen.css",
        "css/indefero.css",
        "js/global.js"
    ],
    "ignore": [
        ".jshintrc",
        "**/*.txt"
    ],
    "private": true,
    "dependencies": {
        "jquery": "~1.*",
        "bootstrap": "3.0.*",
        "jquery.browser": "latest",
        "jquery-colorbox": "latest",
        "jquery-cookie": "latest",
        "scroll-to-top": "latest",
        "headjs": "latest"
    }
}

Commentaires

greg0ire

Autre inconvénient: il n'y a pour l'instant pas de bower.lock. Du coup, pour l'instant, tu n'as pas tellement le choix, il vaut mieux versionner les fichiers si tu veux éviter de te retrouver avec des fichiers différents en prod et en dev. Ou alors trouver une tâche Capistrano permettant de faire un rsync de ton dossier bower_components (ou vendor ?).

llaumgui

Quand tu parles de .lock tu compares à composer.

Perso, je ne suis pas fan du .lock qui pour moi tient plus d'un cache. Si tu veux cibler une version, il faut écrire les bonnes règles dans ton .json et non pas compter sur le .lock.

PapsOu

Concernant la « Minification », as-tu déjà vu ce qui se fait du côté de Compass / sass / scss ?

Je l'utilise dans notre projet SF2 actuellement. Je le trouve plutôt difficile à mettre en place et à gérer les bug liés à la mise en place, mais une fois déployé et paramétré correctement, ça tourne du tonnerre.

llaumgui

Pour minifier, je pensais plutôt utiliser une tâche grunt.

Les commentaires pour ce poste sont fermés.

Réseaux sociaux