Appliquer un correctif aux dépendances Composer : Cloner le dépôt original

Rédigé par Sylvain Lavielle
Développeur web freelance expert Drupal sur Toulouse

Le 06/09/2019
keyboard_arrow_left Bonne lecture ? Que diriez-vous de partager. sentiment_satisfied_alt

Dans un premier article, j'avais présenté une première méthode permettant de répondre à ce problème. Celle-ci consistait à appliquer le correctif à l'aide d'un patch appliqué automatiquement via Composer.

Voici un seconde méthode permettant également de résoudre ce problème. Elle consiste à substituer au dépôt original un clone de celui-ci contenant le correctif et à indiquer à Composer d'aller chercher la dépendance à cet endroit plutôt que dans le dépôt original.

Utiliser un dépôt alternatif pour une dépendance

Imaginons par exemple que j'utilise la librairie currency-converter. Cette librairie est référencée de façon normale dans le composer.json :

"require": {
    "ujjwal/currency-converter": "^2.3",
}

J'ai détecté un problème qui doit être résolu pour me permettre d'utiliser cette librairie dans le cadre de mon projet.

Dans un premier temps, je vais cloner ce dépôt et y ajouter mon correctif dans la branche master, puis, comme dans la précédente approche, je vais proposer à l'auteur de la librairie d'intégrer mon correctif via une pull-request. En attendant, je vais devoir dire à Composer d'utiliser les sources présentes dans mon dépôt cloné plutôt que de récupérer les sources de manière classique via packagist.org.

Pour ce faire, il faut créer une entrée dans la section "repositories" afin d'y déclarer le dépôt cloné et indiquer que celui-ci doit servir en lieu et place du repository packagist lorsque la dépendance est requise.

Nous allons indiquer que notre version s'appelle "dev-master" et pointe vers la branche "master" du dépôt cloné où le correctif a été commité.

"repositories": [
    {
      "type": "package",
      "package": {
        "name": "ujjwal/currency-converter",
        "version": "dev-master",
        "source": {
          "url": "https://github.com/slavielle/currency-converter-php",
          "type": "git",
          "reference": "master"
        },
      }
    }
  ],

Puis nous allons maintenant changer la version de notre dépendance dans la section "require" conformément à ce qu'on a déclaré dans la section "repositories".

"require": {
    # "ujjwal/currency-converter": "^2.3",
    "ujjwal/currency-converter": "dev-master",
}

Enfin, pour que la modification soit prise en compte, il nous faudra exécuter la commande :

$ composer install

Ainsi notre dépôt modifié sera utilisé en lieu et place du dépôt packagist original le temps que la pull-request soit acceptée et mergée par l'auteur et qu'une nouvelle release l rende le correctif disponible.

Lorsque ce sera le cas, il nous faudra alors :

  • restaurer l'appel original à la dépendance dans la section "require",
  • supprimer notre enregistrement dans la section "repositories",
  • exécuter à nouveau un "composer install" pour récupérer le code de la dépendance via packagist.org.

Quelle approche privilégier ?

Entre la méthode par application d'un patch présentée dans le précédent article et la méthode présentée ici, j'ai personnellement une préférence pour la méthode utilisant un patch. Cette dernière ne nécessite pas de modifier la référence au dépôt original et donc permet de bénéficier des éventuelles mises à jour (potentiellement de sécurité) de la dépendance.

Dans cette seconde méthode on change le dépôt à partir duquel la dépendance est récupérée, et si on veut bénéficier des mises à jour éventuelles de la dépendance il nous faudra alors les merger nous même du dépôt original vers notre dépôt cloné.

De plus Il est relativement facile d'oublier qu'on utilise un dépôt alternatif dans l'attente que notre correction soit intégrée. On crée alors sans le vouloir une version figée de la dépendance qui n'évoluera plus et ne bénéficiera plus d'aucun correctif ni d'aucune évolution.

C'est donc une technique plus piégeuse que la technique par application de patch. Elle peut cependant être utilisée si vous souhaitez vraiment maintenir une version alternative d'une librairie dans la durée.

Sujets abordés dans cet article