Quelle est la différence entre CodeKit et Composer ?

Depuis que j’ai écrit sur CodeKit et Composer (plus sur ce dernier dans des articles récents, vraiment), je reçois parfois des e-mails me demandant ce que je préfère vraiment utiliser lorsqu’il s’agit de travailler sur des projets pour d’autres.

Et la réponse courte est qu’ils ne sont pas mutuellement exclusifs. Si quoi que ce soit, ils peuvent se compléter. Ils ne se substituent pas l’un à l’autre.

Plus je suis passé de projets de moins en moins orientés frontend, moins j’utilise CodeKit. Et plus j’évolue vers un développement orienté backend, plus j’utilise Composer.

De plus, le développement front-end est différent du développement back-end, n’est-ce pas ? Alors, encore une fois, pourquoi demanderions-nous :

Dois-je utiliser CodeKit ou Composer ?

C’est là que la réponse plus longue entre en jeu.

CodeKit et Composer

Pour ceux qui regardent ces deux utilitaires et s’interrogent sur la différence entre chacun, c’est une bonne chose.

Chaque fois que quelqu’un cherche des moyens d’améliorer son processus de développement grâce à l’utilisation d’outils pour faciliter le développement, je pense que cela montre un niveau de maturité dans le développement.

Code Kit

En bref, l’objectif de CodeKit est d’aider à intégrer un grand nombre des nouveaux outils que nous voyons souvent (comme Sass ou LESS, des frameworks tels que Foundation et l’optimisation d’image) dans une seule application et de la résumer, il y a donc moins de travail à faire quand il vient à la configuration.

Le problème, c’est qu’il contient beaucoup de choses. Ce n’est pas une mauvaise chose, cependant. Il s’agit vraiment de sélectionner ce que vous voulez, de cliquer sur quelques cases à cocher, puis de vous assurer que l’application est consciente de votre base de code.

À partir de là, il s’occupera, par exemple, de compiler automatiquement votre Sass chaque fois que vous enregistrez un fichier faisant partie de votre projet.

Compositeur

Composer, d’autre part, consiste à gérer les dépendances qui fonctionnent conjointement avec votre application. Cela peut être quelque chose comme PHP CodeSniffer. Ou cela peut être quelque chose comme une bibliothèque tierce comme Monolog qui aide votre projet à suivre les événements qui se produisent pendant l’exécution.

Quoi qu’il en soit, vous pouvez voir que les packages que Composer est chargé de gérer traitent davantage du développement côté serveur que du développement frontal.

Donc, si vous cherchez quelque chose comme CodeKit (ou NPM ou Yarn) pour le côté serveur, alors Composer est ce que vous cherchez à utiliser. Il n’a pas d’interface, donc tout se fait via des fichiers de configuration (comme NPM, par exemple), mais il est également bien documenté et assez facile à utiliser une fois que vous êtes familiarisé avec la structure des fichiers de configuration.

Et c’est la différence

Comme mentionné au début de l’article, CodeKit et Composer ne s’excluent pas mutuellement. Au contraire, ils peuvent travailler en collaboration les uns avec les autres pour aider à construire un projet à la fois du front-end et du back-end.

En ce qui concerne le développement frontal, il existe d’autres outils que les gens choisissent d’utiliser, tels que NPM et Yarn. Je les mentionne ici uniquement parce qu’ils sont également des gestionnaires de packages, un peu comme Composer, mais pour le front-end.

Et, au contraire, ils sont plus proches d’une comparaison avec Composer. Même encore, ils se concentrent principalement sur les outils de développement front-end. Peut-être que cela vaudra la peine de plonger dans chacun d’eux dans un prochain article.