GraphiQL 6 refond l'interface et change la façon d'envoyer les requêtes
· Rédaction BehindLines
GraphiQL, l'outil pour écrire et tester des requêtes GraphQL dans le navigateur, passe en version 6. Selon l'annonce publiée le 7 novembre 2026 sur le blog de graphql.org par Trevor Scheer, ce chantier a été financé par le programme de subventions de la communauté GraphQL. La page de publication sur GitHub date la version 6.0.0 du 1er novembre.
Une interface repensée autour des éditeurs
Les éditeurs de code avaient déjà basculé vers Monaco dans la version 5. La version 6 reprend toute l'organisation de l'espace de travail : navigation, onglets, menus et boîtes de dialogue. Les notes de version mentionnent des thèmes clair et sombre, une barre de point d'accès, un panneau latéral redimensionnable et une barre d'état. L'annonce précise aussi que les indicateurs de focus au clavier sont plus lisibles et que des contrôles d'accessibilité automatiques tournent désormais avec les autres tests.
Trois nouveautés pour le quotidien
- Constructeur de requêtes : on coche des champs du schéma et l'opération s'écrit dans l'éditeur. On peut passer du constructeur au texte, extraire des champs dans un fragment réutilisable ou transformer un argument en variable.
- Collections : les opérations s'enregistrent par nom, se partagent sous forme de JSON et s'importent sans doublon. Par défaut, elles sont conservées dans le navigateur ; une organisation peut brancher son propre stockage.
- Réponse en trois vues : JSON brut, arbre repliable ou tableau. Le choix est mémorisé d'un rechargement à l'autre.
L'API « transport » remplace peu à peu « fetcher »
Le changement le plus technique concerne l'envoi des requêtes. La nouvelle API `transport` renvoie, avec le résultat, des informations HTTP : méthode, statut, durée et taille de la réponse. Pour choisir la méthode, elle interroge d'abord le serveur avec une requête OPTIONS et lit l'en-tête `Allow`. Pour une requête de lecture, elle préfère QUERY, puis POST, puis GET ; si la découverte échoue, elle retombe sur POST, et les mutations utilisent toujours POST. Le projet recommande de migrer, mais `fetcher` reste utilisable et n'est que déprécié.
Ce qu'il faut vérifier avant de mettre à jour
L'annonce ne détaille pas les ruptures de compatibilité et renvoie à un guide de migration. Les notes de version, elles, en listent plusieurs : les versions 15 et 16.0 à 16.10 de graphql-js ne sont plus prises en charge, le greffon Explorer cède la place au constructeur de requêtes, la propriété `operationName` disparaît, et les anciennes variables CSS `--color-*` ne stylent plus l'interface, remplacées par des jetons OKLCH. Pour une intégration existante, l'annonce conseille de commencer par le guide de migration.