Charger vos librairies front via composer

De nombreux modules requièrent des librairies front externes pour fonctionner correctement. Plutôt que les charger manuellement, cet article explique comment les gérer via composer.

Depuis la sortie de Drupal 8, composer est devenu la façon la plus répandue de gérer les dépendances des projets. Ainsi, nous pouvons charger modules contribués et thèmes de façon unifiée ainsi que, si nécessaire, les librairies PHP dont ils dépendent. Cependant, certains modules ont besoin de librairies venant du monde du front et n'étant pas nativement supportées par composer. Ainsi, pour chacun de ces modules, il est nécessaire d'aller télécharger la librairie manuellement et de l'ajouter dans son dépôt de code. Il faut ensuite suivre régulièrement les mises à jour de toutes les librairies de tous les projets et les télécharger de nouveau en cas d'évolution ou de faille de sécurité.

Ça, c'était avant.

Cela fait bien longtemps maintenant que cette problématique a été résolue par les personnes travaillant sur le front des projets via divers package managers comme npm et bower, dont composer est d'ailleurs inspiré. Mais alors, pourquoi est-ce si compliqué de gérer ces librairies dans Drupal ?

npm, bower et composer ne référencent pas les mêmes types de paquets. En effet, les paquets PHP n'ont pas la même organisation et le même usage que les paquets Javascript. Cependant, même s'il est techniquement possible de déclarer un paquet Javascript dans packagist (la base de données alimentant composer), les auteurs de ces paquets ne le font généralement pas pour ne pas avoir à gérer tous les gestionnaires de paquets du monde et parce que cela n'est généralement pas pertinent pour l'usage que l'on peut faire de leur outil. Les personnes maintenant des outils Javascript se concentrent donc sur npm et bower, les deux plus utilisés.

Bienvenue Asset Packagist

La communauté étant pleine de ressources, le projet Asset Packagist a émergé pour répondre à ce besoin. Son but, mettre à disposition les paquets présents sur npm et bower via composer à moindre effort. Ainsi, il est possible de récupérer ces dépendances et de les maintenir à jour de la même façon que le reste de nos modules.

composer étant configuré pour uniquement chercher ses paquets sur son propre packagist, nous allons devoir tout de même procéder à quelques configurations dans notre projet pour pouvoir utiliser Asset Packagist comme source, suivez le guide !

Configurer le repository

Comme lorsque l'on souhaite pouvoir récupérer les modules et thèmes de Drupal, nous devons déclarer un repository spécifique au sein de notre fichier composer.json. Voilà à quoi ressemble la section repositories de mon fichier :

    "repositories": {
        "drupal": {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        "assets": {
            "type": "composer",
            "url": "https://asset-packagist.org"
        }
    },

Désormais, vous avez la possibilité de récupérer les dépendances front de vos modules via les commandes composer require npm-asset/PAQUET ou composer require bower-asset/PAQUET en cherchant sur le site d'Asset Packagist le nom correspondant.

Cependant, en l'état nos dépendances seront installées dans le dossier /vendor, comme les dépendances PHP, ce qui ne nous arrange pas puisque les modules les chercheront dans le dossier /libraries pour les rendre accessibles aux visiteurs.

Configurer l'emplacement des librairies

Pour faire en sorte que composer place les fichiers à l'endroit voulu, il nous faut exploiter les possibilités offertes par le paquet composer/installers. Si ce dernier n'est pas déjà installé dans votre projet (ce qui est peu probable si vous gérez vos modules via composer), il vous suffit de taper la commande composer require composer/installers pour ajouter la dépendance.

Ensuite, il faut ajouter quelques informations dans la section extra de votre composer.json.

  • L'entrée installer-types permet de déclarer les types de paquets en provenance de Asset Packagist.
  • L'entrée installer-paths permet de déterminer l'endroit où chaque type de paquet sera déposé. Dans le code ci-dessous, les déclarations ont été ajoutées à celles de Drupal.
    "extra": {
        "installer-types": ["bower-asset", "npm-asset"],
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": [
                "type:drupal-library",
                "type:bower-asset",
                "type:npm-asset"
            ],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/Commands/contrib/{$name}": ["type:drupal-drush"],
            "web/modules/custom/{$name}": ["type:drupal-custom-module"],
            "web/themes/custom/{$name}": ["type:drupal-custom-theme"]
        },
    }

Et voilà, votre projet est prêt à recevoir ces dépendances et à les maintenir à jour suivant le même processus que vos modules et vos thèmes !

Commentaires

olivier Lundi 4 octobre 2021 - 16:15
Merci pour cet article bien détaillé. Je me pose juste la question de comment surveiller les mises à jour disponibles pour ces librairies.. En effet pour Drupal il y a soit l'option d'activer le module Update Manager, ou de lancer régulièrement un "composer outdated drupal/*". Quel est ta solution pour ça ? Merci <3
En réponse à par olivier
DuaelFr Lundi 4 octobre 2021 - 16:26

Il n'y a pas (à ma connaissance) de module magique pour vérifier ça à ta place. Cependant, la commande composer outdated -D permet de remonter toutes les mises à jour de paquets explicitement requis dans ton composer.json donc tu y verras tous les modules, thèmes et librairies que tu as ajouté mais pas leurs propres dépendances.

olivier Lundi 4 octobre 2021 - 16:30
Oh chouette cette option "-D", je n'avais pas poussé l'usage de la commande "outdated" en dehors des modules Drupal ; Le peu de test que j'avais fait me ressortait vraiment toutes les mises à jour possible, de toutes les dépendances ! Merci

Votre commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
Votre adresse servira à afficher un Gravatar et à vous notifier des réponses. Votre commentaire sera anonymisé si ce billet est dépublié pendant plus de 3 mois.

À propos de Edouard

Expert technique

Après un premier contact douloureux avec Drupal en 2009 en autodidacte, j'ai suivi une formation qui m'a convaincu de mon choix technologique et m'a vraiment mis en selle. Durant plusieurs années suite à cela j'ai accompagné des entreprises locales dans le développement de leurs projets de toutes sortes, de la simple vitrine à l'intranet social en passant par le projet e-commerce.