Meilleur code WordPress : le fichier de verrouillage du compositeur
Avant de conclure notre discussion sur Composer, il nous reste une chose importante à discuter : le répertoire des fournisseurs (et par extension, le fichier de verrouillage de Composer).
Plus précisément, nous devons expliquer pourquoi nous n’avons pas besoin de valider le répertoire des fournisseurs dans le référentiel, mais comment nos contributeurs peuvent être sûrs qu’ils disposent de la dernière version du logiciel nécessaire pour travailler avec notre base de code.
Utiliser des outils de qualité de code pour écrire un meilleur code WordPress est important, oui, mais comprendre comment gérer correctement les dépendances et notre référentiel est également important. Donc, avant de regarder lesdits utilitaires, passons en revue le fichier de verrouillage, le rôle qu’il joue et pourquoi nous n’avons pas besoin de valider le répertoire du fournisseur dans notre référentiel.
Meilleur code WordPress avec le fichier de verrouillage Composer
Pour ceux qui travaillent avec WordPress – et peut-être dans d’autres frameworks et fondations basés sur PHP (je ne sais pas vraiment car j’ai tendance à ne pas travailler avec eux) – il y a une dépendance à Composer, ce qui est une bonne chose.
Cela peut également conduire à vouloir valider l’intégralité du contrôle de source du répertoire du fournisseur, ce qui n’est pas une bonne chose.
Comme mentionné dans le post précédent :
Et je ne recommande pas de vérifier le répertoire du fournisseur dans votre référentiel. Cela peut devenir un énorme répertoire plus tard, et cela peut saper tout l’objectif de Composer.
Alors, comment pouvons-nous nous assurer que nous ne commitons pas inutilement des fichiers (et donc gonflons la taille de notre référentiel) dans le référentiel tout en nous assurant que nos contributeurs utilisent la même version du logiciel que nous ?
Le désir d’engager le répertoire des fournisseurs
Pour ceux d’entre vous qui ont exécuté Composer et qui connaissent au moins le répertoire du fournisseur, vous êtes probablement habitué à voir plusieurs répertoires de dépendances installés.
Et ils sont utiles; sinon, vous ne les auriez pas inclus, n’est-ce pas ?
Mais voici le problème avec le répertoire du fournisseur : même si vous n’avez installé que quelques dépendances avec votre projet, la taille du fichier lui-même peut être importante. Et cela peut être encore plus important lorsque vous avez beaucoup de dépendances.
Quoi qu’il en soit, s’engager dans le contrôle des sources semble avoir du sens, n’est-ce pas ? Nous voulons nous assurer que tout le monde a la même version du logiciel que nous utilisons et nous voulons nous assurer qu’ils n’ont pas à traiter avec Composer.
Il y a une autre façon, cependant. Et cela maintient notre référentiel petit tout en s’assurant que les versions de nos dépendances sont synchronisées avec ceux qui clonent le référentiel, s’engagent dans le référentiel ou pour tout utilitaire d’intégration continue qui utilise le référentiel.
Comprendre le fichier de verrouillage
Avant de parler du répertoire des fournisseurs, je souhaite aborder un autre aspect important de Composer : le fichier de verrouillage. Autrement dit, si vous exécutez la commande d’ installation ou de mise à jour dans votre terminal, vous verrez un fichier de verrouillage généré avec le répertoire du fournisseur.
C’est quoi ce fichier ?
Le post précédent montrait un exemple de fichier de configuration. L’une des choses que ce fichier nous permet également de faire est de définir des bibliothèques tierces, ou des dépendances, que nous pouvons utiliser dans nos projets.
J’en ai parlé dans d’autres articles (et nous pourrons y revenir un peu plus tard dans cette série). Mais c’est là que le fichier de verrouillage entre en jeu.
En bref, le fichier de verrouillage contient toujours des informations sur la version – la version exacte – des dépendances utilisées avec le projet lors de la dernière exécution de l’ installation ou de la mise à jour.
Lorsque Composer a terminé l’installation, il écrit tous les packages et les versions exactes de ceux-ci qu’il a téléchargés dans le fichier composer.lock, verrouillant le projet sur ces versions spécifiques.
Vous devez valider le fichier composer.lock dans votre référentiel de projet afin que toutes les personnes travaillant sur le projet soient verrouillées sur les mêmes versions de dépendances (voir ci-dessous).
L’objectif est de s’assurer que tout le monde exécute la même version des dépendances du projet – pas des versions plus anciennes, pas des versions plus récentes – mais la même version.
Ainsi, lorsque vous exécutez composer install lorsqu’un fichier de verrouillage est inclus dans le référentiel, il utilise la version du logiciel telle que définie dans le fichier de verrouillage.
Et cela garantit que tout le monde exécute la même version de chaque dépendance et peut ainsi éviter d’avoir à valider le répertoire du fournisseur dans le contrôle de code source.
Écrire du code de meilleure qualité
Alors, où allons-nous partir d’ici?
Maintenant que nous comprenons comment utiliser Composer et comment utiliser le fichier de verrouillage, nous pouvons commencer à parler des dépendances réelles qui aident à améliorer la qualité de notre code.
Et lorsque nous parlons d’écrire du code de meilleure qualité, il existe des utilitaires conçus exactement pour cela. Ainsi, dans les prochains articles, nous allons en examiner quelques-uns.