Si vous me suivez depuis un petit moment déjà, vous devez savoir que j’avais choisi de gérer les dépendances de mon projet en utilisant le système de sous module de git : git submodule. Récemment, j’ai décidé de changer de système pour la gestion de dépendances du projet. Retour sur ce revirement …
Contenus de la page
Pourquoi changer ? git submodule ne convenait plus ?
La réponse peut paraître étonnante, mais si, git submodule convenait parfaitement et répondait de façon correcte au besoin de gestion des dépendances.
Cependant, l’un des principal défaut de git submodule – comme je l’exposais dans mon précédent billet – c’est que Github (la plateforme sur laquelle est hébergé le code source du projet) ne tient pas compte des sous modules lors de la création des archives .zip automatiques.
D’autre part, il semblerait que peu de développeurs connaissent/sachent utiliser les sous modules dans git :anguished:
Enfin, la gestion des dépendances du projet n’est pas aisée. En effet, on ne dispose pas d’un fichier détaillant l’ensemble des dépendances utilisées par le projet ni quelle est la version utilisée. Cela rend d’autant plus difficile le suivi des mises à jour des dites dépendances.
Deux nouveaux gestionnaires de dépendances.
Pourquoi deux ? Tout simplement parce qu’ils ne répondent pas au même besoin, l’un se chargera d’installer des dépendances backend (framework, plugins, librairies serveur) tandis que l’autre gèrera les dépendances frontend (framework css, librairies clientes javascript, etc.)
Composer pour la gestion des dépendances Backend.
Cela fait environ deux ans qu’on entend parler de Composer. C’est le même principe que les gestionnaires de paquets sous GNU/Linux. À vrai dire, d’ailleurs, rien de nouveau sous le soleil puisque le projet PEAR proposait déjà cela depuis un bon bout de temps.
Là où Composer réussi à faire mieux, c’est qu’il rend la vie beaucoup plus facile à l’utilisateur final en laissant au développeur la possibilité de spécifier un fichier composer.json
contenant le détail de l’ensemble des dépendances à installer. Il est également possible de distinguer les dépendances de développement de celles de production.
Voici un exemple de fichier composer.json
.
Comme vous pouvez le constater, la syntaxe de ce fichier – rédigé en utilisant la JSON permet de le rendre très lisible.
Composer est un outil très souple puisque outre l’installation de paquets depuis le dépôt de paquets centralisé Packagist.org, il permet également l’installation de paquets depuis des dépôts Git et PEAR (encore utilisé par CakePHP).
L’outil permet également de verrouiller une dépendance sur une révision en particulier en spécifiant le hash de commit (comme en lignes 16 et 17).
L’installation est très simple, puisqu’il suffit de taper la ligne de commande suivante à la racine du projet pour installer Composer :
Et pour récupérer les dépendances du projet un simple php composer <span class="token function">install</span>
suffit !
Bower gère les dépendances Frontend.
Bower, c’est le nom de ce merveilleux petit oiseau. Ce gestionnaire de dépendances Frontend nous viens de l’équipe de Twitter, aussi auteure du merveilleux framework CSS Bootstrap !
Bower permet de gérer l’installation et la mise à jour de vos librairies Javascript/CSS parmi un dépôt de plus de 6700 composants.
Tout comme Composer, Bower se base sur un fichier bower.json
pour l’installation des dépendances.
Il est à noter que Bower permet également l’installation de dépendances Frontend de façon arbitraire (lignes 6 et 9), simplement en lui fournissant un fichier d’archive (.zip, .tar.gz, etc.).
On peut également choisir le répertoire dans lequel on souhaite télécharger les dépendances en le spécifiant dans un fichier .bowerrc
.
L’installation est légèrement plus compliquée que Composer puisque Bower nécessite l’installation au préalable de Node.js et npm pour fonctionner. Cependant, des paquets pré-compilés existent sur le site officiel du projet.
Une fois Node.js installé, Bower s’installe très simplement en tapant <span class="token function">npm</span> <span class="token function">install</span> -g bower
. On peut ensuite récupérer les dépendances du projet en tapant un petit bower <span class="token function">install</span>
😉
versioneye, la cerise sur le gâteau.
versioneye est un SaaS qui vous permet de garder un oeil sur les version de vos dépendances de façon à savoir si celles-ci sont à jour ou obsolètes. Il est possible d’importer vos projet directement depuis Github. Pour le moment, le service ne gère que l’analyse de fichier composer.json
mais l’analyse et le suivi des fichiers bower.json
est également prévue 😊
À la prochaine les loulous 😘
Je cherchai cet article pour comprendre la différence entre composer et bower. Merci.
Ping : Vidéo utilisation de Composer | Opencomp.fr – Carnet de développement
As-tu testé Gemnasium ?
Bonjour,
A l’époque où j’ai écrit cet article, Gemnasium ne permettait de suivre que les dépendances des gem ruby.
Je vois que cela a changé et je vais me faire un plaisir de tester leur solution 🙂