Grunt & Bower

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

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"
    }
}
Avatar de Guillaume Kulakowski

À propos de l’auteur

Commentaires

4 réponses à « Bower pour gérer les dépendances du thème de mon blog »

  1. Avatar de 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 ?).

  2. Avatar de 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.

  3. Avatar de PapsOu
    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.

  4. Avatar de llaumgui

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

Derniers articles sur le journal

  • SeedboxSync v4.1 : Authentification OIDC, Gravatar et refonte de l’administration
    Découvrez les nouveautés de SeedboxSync v4.1 : intégration d’un système d’authentification natif et OIDC (SSO), support de Gravatar, gestion des utilisateurs en CLI, formulaires Flask-WTForm et transition vers Peewee-Migrate.
  • De Jellystat à Jellydash : moderniser le suivi de mon serveur Jellyfin
    Pourquoi et comment j’ai remplacé Jellystat par Jellydash pour le suivi des statistiques de mon serveur Jellyfin. Retour d’expérience sur la découverte de cet outil moderne, léger et prometteur repéré dans la newsletter selfh.st.
  • SeedboxSync 4.0 : Fusion de l’IHM et du CLI
    La v4.0.0 de SeedboxSync marque un tournant majeur : fusion du CLI et du frontend en une seule application, migration de la configuration en base de données, planificateur Python natif et passage à SQLite WAL. Tour d’horizon des nouveautés et des changements d’architecture.
  • Modernisation du tooling dev sur SeedboxSync : Just, pnpm, uv & Ruff
    SeedboxSync fait peau neuve côté tooling ! Retour sur la modernisation de mon environnement de dev : abandon du bon vieux Makefile au profit de Just, transition vers pnpm pour un gain de temps spectaculaire côté frontend, et adoption de uv et Ruff pour booster l’écosystème Python. Moins de friction, plus de vitesse : découvrez le détail de cette mise à jour.

Articles à la une