Symfony enfile la casquette du linter CI — et ça va vous faire gagner un temps fou
On l'attendait presque, et la voilà: l'équipe Symfony vient de dévoiler symfony lsp:check, une nouvelle commande du Symfony CLI capable d'appliquer les règles de diagnostic du Language Server Protocol directement dans vos pipelines d'intégration continue. Fichiers statiques, routes, templates Twig, traductions… le tout, sans ouvrir un éditeur. Oh, et au passage, l'outil a été pensé pour que les agents de codage autonomes puissent valider leurs propres modifications avant même qu'un humain ne jette un œil à la pull request. Autrement dit, on passe de « mon IDE me signale un truc au moment où je tape » à « ma CI me dit que c'est cassé avant que je merge ». Game changer, ou simple évolution logique? Un peu des deux, en vrai.
Pourquoi on devrait tous s'en soucier (même les sceptiques)
L'idée fondamentale, c'est de déplacer la détection des erreurs là où elle a le plus de valeur: dans le pipeline, quand le code est prêt à être intégré, pas quand le développeur est déjà passé à autre chose. Concrètement, symfony lsp:check réutilise la même couche de diagnostic que votre LSP dans VS Code ou PhpStorm, mais appliquée de façon statique et automatisée. Résultat? Des routes cassées, des variables Twig non typées ou des clés de traduction manquantes qui remontent avant qu'elles n'atterrissent en production — sans avoir à configurer un linter dédié supplémentaire.
Pour ceux qui bossent sur des gros monolites legacy (oui, on vous voit), c'est une porte d'entrée assez douce pour durcir le CI sans refondre tout le tooling. Et pour l'écosystème des agents IA qui commencent à écrire du code PHP pour nous (on y vient, hein, faut pas se voiler la face), c'est un garde-fou bienvenu: l'agent pousse, la CI vérifie, l'humain décide. L'ordre des choses qui a du sens.
Et pendant ce temps, côté Blade…
Côté Laravel, un autre outil fait parler de lui: Forte, développé par John Koster, un parseur dédié aux templates Blade qui génère un arbre syntaxique typé — interrogeable via XPath pour appliquer des refactorisations automatisées. L'idée, c'est de remplacer les expressions régulières artisanales (celles qui cassent trois vues sur quatre quand on renomme un composant) par une approche structurelle propre. Besoin de trouver tous les <a> sans href> dans une <nav> sur 400 vues? Une expression XPath. Besoin de renommer un composant partout? Un script, pas un find-and-replace aveugle. Forte requiert PHP 8.2 et l'extension dom, et s'intègre directement dans Laravel 10 à 13 via un service provider.
C'est un peu la même philosophie que lsp:check pour Symfony: on passe du bricolage textuel à de l'analyse structurelle sérieuse. Les deux outils n'ont pas les mêmes cibles, mais le signal est le même — l'écosystème PHP mature vers un tooling qui comprend réellement le code, pas juste son texte brut.
Ce qu'on devrait faire maintenant
Si vous êtes sur Symfony: gardez un œil sur la sortie stable de symfony lsp:check et testez-la sur un projet pilote dès que possible. Intégrer ne serait-ce que la vérification des routes et des traductions dans votre CI pourrait vous éviter des surprises au déploiement. Si vous êtes sur Laravel et que vous gérez des refactorings de vues Blade à grande échelle, Forte mérite un PoC — la courbe d'apprentissage XPath n'est pas si pentue qu'on le croit, et le gain en fiabilité, lui, est immédiat.
Dans les deux cas, on parle d'outils qui font confiance à l'analyse syntaxique plutôt qu'aux heuristiques fragiles. Et honnêtement, c'est exactement la direction qu'on veut voir prendre l'écosystème. Vous en pensez quoi?