« WordPress 6.5 apporte l’Interactivity API, une nouvelle façon standardisée de construire des expériences interactives basées sur les blocs. » Cette phrase, tirée des notes de version officielles publiées en avril, ne dit rien de ce qu’elle implique concrètement pour la chaîne de build JavaScript des thèmes et extensions maintenus par une agence. Sur nos projets, la question n’était pas de savoir si l’Interactivity API était pertinente sur le plan fonctionnel, mais ce qu’elle change dans les fichiers de configuration webpack, les dépendances npm et les scripts de build existants.
Cet article ne traite pas de la manière d’implémenter une interaction spécifique avec l’API ; il se concentre uniquement sur l’impact en amont, côté outillage de build, pour les projets qui doivent absorber cette nouveauté du cœur sans repartir de zéro.
Un nouveau module à ajouter aux dépendances
L’Interactivity API s’appuie sur un nouveau paquet, @wordpress/interactivity, distinct du système d’événements JavaScript utilisé jusqu’ici dans la plupart des blocs personnalisés. Pour un projet géré via @wordpress/scripts, ce paquet s’ajoute simplement aux dépendances du thème ou de l’extension, mais son intégration au build nécessite de vérifier que la configuration webpack expose correctement le nouveau store d’interactivité en tant que dépendance externe, plutôt que de le regrouper dans le bundle final.
{
"dependencies": {
"@wordpress/interactivity": "^5.0.0"
}
}
Sur un projet utilisant @wordpress/scripts en version à jour, cette externalisation est gérée automatiquement par le preset webpack fourni par l’outil, ce qui évite d’avoir à modifier soi-même la configuration dans la majorité des cas. Les projets qui maintiennent une configuration webpack personnalisée, en dehors du preset officiel, doivent en revanche l’ajouter explicitement à la liste des externals.
Les block bindings changent la génération de certains attributs
L’API de liaison de blocs (block bindings), dont l’API publique arrive avec cette version après une phase expérimentale entamée l’année précédente, introduit un nouvel attribut metadata.bindings dans la structure JSON des blocs. Les scripts de build qui analysent ou transforment le contenu des blocs — par exemple un script maison de linting de contenu, ou un outil de migration de contenu entre environnements — doivent être mis à jour pour reconnaître cette nouvelle structure sans la considérer comme une erreur de format.
La Font Library ajoute une source de fichiers à surveiller
La nouvelle bibliothèque de polices intégrée à l’éditeur permet désormais d’installer des polices directement depuis l’interface d’administration, stockées dans wp-content/uploads/fonts. Pour les projets où le répertoire uploads est exclu du dépôt Git par convention (ce qui est la norme sur nos projets), cela signifie qu’une police installée via l’interface sur un environnement ne sera pas automatiquement présente sur un autre. Le script de synchronisation de médias entre environnements doit désormais inclure ce sous-répertoire, qui échappait auparavant à toute synchronisation puisqu’il n’existait pas.
- Vérifier que le script de synchronisation de médias entre staging et production couvre bien
wp-content/uploads/fonts. - Documenter, pour l’équipe, que l’installation d’une police via l’éditeur nécessite désormais une étape de synchronisation manuelle ou automatisée vers les autres environnements.
- Prévoir cette synchronisation dans les scripts de déploiement existants si des polices sont ajoutées en production directement.
Ce qui ne change pas dans le build
Les outils de build eux-mêmes — @wordpress/scripts, la configuration Babel sous-jacente, le système de traduction des chaînes JavaScript via @wordpress/i18n — restent inchangés par cette version. Il n’y a pas de rupture de compatibilité à anticiper pour les blocs existants qui n’adoptent pas l’Interactivity API : ils continuent de fonctionner avec leur système d’événements JavaScript classique sans modification requise.
Vérifier sa configuration avant de monter en version
Sur nos projets, la montée vers WordPress 6.5 s’est faite en trois vérifications précises : confirmation que @wordpress/scripts était en version récente pour bénéficier de l’externalisation automatique du nouveau module d’interactivité, ajout du sous-répertoire de polices aux scripts de synchronisation de médias, et test des outils internes d’analyse de contenu contre la nouvelle structure des block bindings sur un environnement de staging avant toute mise à jour en production.
Une nouvelle version du cœur qui ajoute une API n’oblige jamais à l’adopter immédiatement, mais elle oblige presque toujours à vérifier que l’outillage de build ne casse pas silencieusement sur les nouvelles structures qu’elle introduit.
En résumé
WordPress 6.5 change peu de chose dans la chaîne de build pour les projets qui n’adoptent pas immédiatement l’Interactivity API, mais trois points méritent une vérification systématique avant la montée de version : la gestion du nouveau module d’interactivité par le preset de build, la compatibilité des outils internes avec la structure des block bindings, et la synchronisation du nouveau répertoire de polices entre environnements.
