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
Rodriguez Mercredi 24 novembre 2021 - 14:21
Bonjour, J'ai souvi votre billet et j'ai essayé d'installer "npm-asset/video.js". Ça marche parfait et je vois bien le dossier "video.js" dans "web/libraries". Cependant je vois aussi d'autres librairies (j'imagine qu'elles sont de dépendances). Existe-t-il un moyen avec composer d'installer uniquement la librairie "video.js" sans les dépendances ? 
En réponse à par Rodriguez
DuaelFr Jeudi 25 novembre 2021 - 10:32

Ce sont effectivement les dépendances déclarées par le paquet video.js sur npm. Malheureusement il n'existe pas à ma connaissance de méthode pour demander à composer de ne pas récupérer les dépendances d'un paquet. Cependant, celles-ci ne sont pas gênantes car elles sont juste téléchargées mais pas incluses dans la page par Drupal. À moins d'avoir un tout petit espace sur le disque dur du serveur, cela n'aura pas d'impact sur le site.

En réponse à par DuaelFr
Rodriguez Jeudi 25 novembre 2021 - 14:54
Merci pour la réponse, mais ça me pose un souci d'avoir dans "web/libraries" d'autres librairies qui ne sont pas utilisées par Drupal, rien que toutes les dépendances de videojs font plus de 4000 fichiers qui font presque planter mon git. Je préfèrerais avoir dans "web/libraries" uniquement les libraries qui sont utilisées par Drupal. Ce que je trouve drôle par contre, c'est que si l'on installe la version bower avec "composer require bower-asset/videojs" ça n'installe que videojs et ça n'installe aucune autre dépendance... savez-vous pourquoi ? Du coup je pense que je vais utiliser tout le temps les versions "bower" si c'est comme ça.
En réponse à par Rodriguez
DuaelFr Jeudi 25 novembre 2021 - 15:15

Nous n'ajoutons généralement pas les fichiers récupérés via composer à nos dépôts de code donc nous n'avons effectivement pas ce problème. Cela dit, rien ne vous empêche d'ajouter web/libraries à votre .gitignore et de ne commit (en force) que les librairies dont vous avez vraiment besoin.

Je ne sais pas pourquoi la récupération de la librairie via bower n'inclut pas les dépendances. Tant mieux si ça vous arrange mais attention car c'est peut-être un bug passager.

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.
Pour lutter contre le spam notre système enregistre votre adresse IP et votre adresse e-mail si vous la partagez.
Nous vous invitons à consulter notre politique de confidentialité pour comprendre les traitements faits de ces données et comment les rectifier.

À 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.