Renommer une variable dans son éditeur, tout le monde le fait sans y penser. Déplacer une fonction dans un autre paquet, ajouter des tags à une struct avec la bonne convention de nommage ou implémenter une interface sans recopier chaque signature à la main, c’est une autre histoire. L’équipe Go vient de présenter une réponse à ce problème : le refactoring interactif dans gopls, le serveur de langage officiel du langage.
Plan de l'article
Ce que l’équipe Go annonce #
Dans un billet publié le 16 octobre sur le blog officiel de Go, Hongxiang Jiang explique que gopls peut désormais afficher des boîtes de dialogue en plusieurs étapes dans l’éditeur. Le serveur recueille d’abord les choix du développeur, puis seulement calcule les modifications à appliquer.
Ça a l’air d’un détail, mais ça change la manière dont les outils travaillent. Jusqu’ici, la plupart des « code actions » du protocole LSP s’exécutaient sans paramètre. Le serveur devait deviner l’intention du développeur à partir de la position du curseur et de l’arbre syntaxique. Seul le renommage échappait à cette règle, grâce à un appel dédié, PrepareRename.
Un standard pensé pour tous les langages
Le travail a été mené avec l’équipe de Dart, et l’objectif affiché dépasse Go. Le billet parle d’un standard ouvert destiné à tous les langages et à tous les éditeurs. Concrètement, il s’agit d’une extension du Language Server Protocol, discutée publiquement dans le ticket n° 1164 du dépôt LSP de Microsoft. Le mécanisme repose sur un protocole de formulaire sans état, au niveau des commandes LSP.
Si la proposition est adoptée, un serveur de langage Rust, Python ou TypeScript pourrait poser des questions au développeur de la même façon, sans que chaque éditeur ait à inventer sa propre interface.
Les refactorings déjà disponibles #
Le billet détaille plusieurs actions qui profitent déjà de ces dialogues.
Ajouter ou retirer des tags de struct
C’est l’exemple le plus parlant pour qui écrit des API. Avant, gopls ajoutait toujours des tags json en camelCase. Désormais, en plaçant le curseur sur une struct et en choisissant « Add struct tags », on obtient un premier champ prérempli avec json, que l’on peut remplacer par une liste comme json,yaml,db. Un second choix porte sur la convention : camelCase, snake_case ou PascalCase. Pour une struct mappée à la fois sur une base de données et sur une réponse HTTP, le gain de temps est immédiat.
À lire PHP 8.6 RC3 : sessions durcies, clamp() et application partielle avant la version stable
Implémenter une interface
L’action « Add methods to X to implement an interface » propose une complétion sur les noms de types, qu’ils viennent de l’espace de travail ou de la bibliothèque standard. gopls génère ensuite les squelettes de méthodes. Plus besoin d’ouvrir la définition de io.Reader ou de http.Handler pour recopier les signatures.
Déplacer une déclaration
C’est la fonction la plus ambitieuse, encore en préversion. « Move declaration » déplace une déclaration avec les fonctions utilitaires dont elle dépend, met à jour les références dans le reste du code et nettoie les imports. Le billet indique qu’elle est prévue pour une prochaine version de gopls.
Quels éditeurs en profitent #
C’est le point à vérifier avant de s’enthousiasmer. La prise en charge complète passe aujourd’hui par l’extension Go officielle de VS Code. Pour Neovim et Emacs, le billet ne mentionne que des intégrations de démonstration, une preuve que le protocole fonctionne ailleurs mais pas encore un outil de tous les jours.
Pour les autres éditeurs compatibles LSP, il faudra attendre que leurs clients implémentent l’extension, ce qui dépend en grande partie de son adoption dans la spécification officielle.
À lire Patch .NET d’octobre : .NET 8 et .NET 9 en fin de support le 10 novembre
Ce que l’équipe prépare ensuite #
Le billet trace trois pistes. La première est le changement de signature, suivi dans le ticket golang/go n° 38028 : réordonner les paramètres d’une fonction ou en ajouter un avec une valeur par défaut, et propager la modification à tous les appels. C’est exactement le genre d’opération qui demande des informations que le curseur ne peut pas deviner.
La deuxième concerne la résolution interactive des conflits : collisions de noms, masquage de variables ou références ambiguës, que l’outil pourrait soumettre au développeur au lieu d’abandonner ou de trancher seul. La troisième sort du cadre de l’édition de code, avec des commandes interactives pour configurer un test ou un benchmark, par exemple en choisissant les profils CPU, mémoire ou de trace.
Ce que ça change dans votre quotidien de dev #
Pour un développeur Go qui travaille sous VS Code, le conseil est simple : mettez à jour l’extension Go et gopls, puis essayez « Add struct tags » sur une struct existante. C’est la démonstration la plus rapide de l’intérêt du dispositif.
Pour les autres, l’intérêt est surtout à moyen terme. Les refactorings sérieux restent aujourd’hui l’apanage des IDE lourds, comme ceux de JetBrains, qui ne passent pas par LSP. Une extension standard permettrait aux éditeurs légers de proposer des opérations comparables, quel que soit le langage. Ce n’est pas encore gagné, mais le fait que deux équipes de Google, Go et Dart, portent ensemble la proposition lui donne un poids réel.
À lire Node.js 26 passe en LTS le 28 octobre : faut-il migrer depuis Node 24 ?
L’équipe invite d’ailleurs les développeurs à donner leur avis, soit sur le gestionnaire de tickets de Go, soit dans la discussion du protocole. C’est le bon moment pour le faire, avant que le format ne soit figé.
