Une nouvelle proposition demande aux contributeurs d'arrêter de fusionner les API expérimentales de Gutenberg vers WordPress Core

La pratique consistant à fusionner les API expérimentales de Gutenberg dans le noyau WordPress pourrait bientôt toucher à sa fin. Une nouvelle proposition, publiée par le contributeur parrainé par Automattic, Adam Zielinski, appelle les contributeurs à stabiliser les API avant de les fusionner dans le noyau.

Au fil des ans, environ 280 API expérimentales ont été fusionnées à partir du plugin Gutenberg, que Zielinski a audité dans un ticket qu'il a ouvert pour le problème en avril. En équilibrant la volonté d'aller vite avec l'itération sur le ou les éditeurs par rapport à l'engagement de WordPress en matière de rétrocompatibilité, le nombre d'API expérimentales est devenu intenable et la pratique consistant à les fusionner dans le noyau est maintenant activement reconsidérée.

Officiellement, les API expérimentales sont signalées comme telles pour décourager l'utilisation par des tiers, car elles sont appelées à changer. En pratique, les personnes qui construisent pour l'éditeur de blocs les utilisent de toute façon parce qu'elles sont dans le noyau et qu'elles souhaitent étendre les fonctionnalités activées par ces API.

"Les auteurs de plugins et de thèmes sont obligés de s'appuyer sur les fonctionnalités __experimental qui pourraient être supprimées ou modifiées de manière rétrocompatible à tout moment", a déclaré Zielinski, faisant écho à la frustration et aux inquiétudes que de nombreux développeurs ont eues avec le projet ces dernières années. « C'est un lourd fardeau d'entretien. Chaque nouvelle version de Gutenberg/WordPress implique des changements potentiellement importants. »

Le principal responsable de WordPress, Peter Wilson, a commenté le ticket, affirmant qu'il était favorable à la limitation des API expérimentales aux produits de pointe. Soulignant la nécessité de ce changement, il a cité une foule d'impacts négatifs que ces API expérimentales de base ont eu sur l'écosystème :

• les committers principaux ne veulent pas utiliser certaines fonctionnalités de la bibliothèque pour faciliter les tâches principales car ils ne font pas confiance à la fiabilité
• les développeurs ne mettent plus à jour les sites clients WP. En tant que core committer qui s'est efforcé de maintenir la rétrocompatibilité pendant des années, cela me déçoit. En tant que membre de l'équipe de sécurité, il est très préoccupant
• les développeurs décidant d'inclure des copies de packages dans des thèmes et des plugins plutôt que de s'appuyer sur les globals wp.* . Encore une fois, cela me préoccupe du point de vue de la sécurité, mais cela augmente également la charge utile JavaScript beaucoup plus que le maintien de la rétrocompatibilité
• rapports de ruptures de compatibilité descendante dans les versions mineures : "vous ne vous attendez pas à ce qu'une version 5.9.1 brise la réactivité d'un tas d'images sur nos sites en dehors de l'éditeur de blocs"
• les développeurs envisagent de ne jamais utiliser de blocs de base car ils sont trop instables : "J'ai arrêté d'utiliser/d'étendre les blocs de base parce qu'ils changeaient trop et j'ai utilisé des blocs ACF pour qu'au moins je sache que je peux créer des blocs qui ne le feront pas Pause. Certes, l'interface utilisateur n'est pas aussi bonne que les blocs de base, mais je prendrai de la stabilité sur les blocs qui se cassent à tout moment.

Le plugin Gutenberg était censé fonctionner comme un plugin de fonctionnalités où des ruptures de compatibilité descendante sont attendues tandis que les contributeurs peaufinent les fonctionnalités avant de les fusionner dans le noyau. Revenir aux racines de cette approche, et rendre l'éditeur moins expérimental, est au centre de cette proposition.

"L'instabilité entre les versions commence déjà à aliéner certains des plus grands défenseurs externes des éditeurs de blocs", a déclaré Wilson.

Le maintien de ce niveau d'instabilité pourrait décourager les gens de construire sur WordPress, les repoussant vers d'autres projets plus simples qui sont gérés d'une manière différente. Il est possible que la nécessité de s'appuyer sur des API expérimentales ait découragé les développeurs de créer davantage de produits, ralentissant ainsi l'adoption de l'éditeur de blocs.

"En tant qu'auteur de plugins qui utilise actuellement de nombreuses API __experimental , j'aimerais les voir stabilisées", a déclaré Nick Diego, contributeur sponsorisé par WP Engine. « La plupart fournissent des fonctionnalités cruciales, mais la création d'un produit qui s'appuie sur une API __experimental est toujours un peu déconcertante. Tant que le processus est extrêmement transparent, bien médiatisé et que nous fournissons aux auteurs de plugins/thèmes un guide sur la façon de migrer vers des versions stables, alors j'aime cette initiative.

Après des mois de discussion sur le ticket, Zielinski a distillé les préoccupations des contributeurs dans le plan d'action proposé sur le blog Make WordPress Core.

La proposition indique que la plupart des API expérimentales existantes déjà fusionnées dans le noyau obtiendraient un alias stable.

"Cela préserverait la rétrocompatibilité et ne devrait pas affecter sensiblement la taille du bundle", a déclaré Zielinski. « Certains auront besoin d'un traitement différent ; discutons-en au cas par cas. Il a également recommandé aux contributeurs de déterminer si une API expérimentale existante déjà dans le noyau doit être supprimée. Il n'anticipe pas de nombreux cas de ce genre, mais recommande que ceux-ci utilisent des pratiques établies consistant à contacter les auteurs de plugins, à utiliser des obsolescences douces et à publier des publications sur le Core.

"Je vois également deux choses en jeu ici : l'utilisation et l'abus d'API expérimentales lors de la conception de l'API (généralement à utiliser et à tester dans le plugin Gutenberg) et l'absence d'un processus diligent pour les stabiliser lorsqu'elles satisfont aux critères de conception", L'architecte principal de Gutenberg, Matias Ventura, a commenté le billet original. "Ceux qui doivent être considérés comme publics de facto sont ceux qui existent depuis de nombreuses versions sous une forme stable malgré leur nomenclature."

Dans l'intérêt de préserver la capacité de WordPress à tenir ses promesses de rétrocompatibilité, la proposition recommande que les API expérimentales soient limitées au plugin Gutenberg et ne soient jamais fusionnées avec le noyau. Dans les cas où une fonctionnalité stable dépend d'une API expérimentale, Zielinski a identifié une réponse simple :

« Alors ce n'est pas réellement stable. Stabilisons d'abord les dépendances.

Il s'agit essentiellement d'une nouvelle façon d'aller de l'avant qui devrait accroître la stabilité et la confiance dans les API et les mises à jour de WordPress, mais elle présente quelques inconvénients.

Les utilisateurs et les contributeurs peuvent s'attendre à ce que les fonctionnalités de Gutenberg soient plus lentes à fusionner avec le noyau, car ils ne peuvent pas s'appuyer sur des API expérimentales lorsqu'ils sont distribués aux heures de grande écoute dans les versions majeures. Zielinski a également noté que les contributeurs peuvent également avoir des difficultés à refactoriser ces API une fois qu'elles ont été expédiées et mises en service sur des millions de sites WordPress.

Jusqu'à présent, la proposition a reçu un soutien extrêmement positif, car beaucoup pensent que ces API n'auraient jamais dû arriver au cœur en premier lieu alors qu'elles étaient encore au stade expérimental.

"Je suis très favorable à cette approche", a déclaré le développeur WordPress Mark Root-Wiley. "Je crée des thèmes personnalisés et j'ai quelques plugins simples. Pour les deux, je me suis retrouvé assez souvent obligé de gérer des API expérimentales et les difficultés de se tenir à jour avec elles lorsque des fonctionnalités sont placées dans le noyau qui ne peuvent être désactivées, ajustées ou étendues que via une API expérimentale.

"Un retour à ce type de stabilité dans le noyau contribuerait grandement à regagner la bonne volonté des développeurs", a commenté Dovid Levine, contributeur de WordPress, sur la proposition.

La date limite pour commenter la proposition est le 7 septembre, ce qui clôturerait la discussion un peu moins de trois semaines avant que WordPress 6.1 Beta 1 ne soit attendu. Cela donne aux contributeurs un peu de temps pour auditer plus en profondeur les API expérimentales avant la prochaine version majeure, s'ils parviennent à un consensus sur leur restriction au plugin Gutenberg.