Annoncée le 31 août 2026, la commande symfony lsp:check rejoue dans l’intégration continue les diagnostics jusque-là réservés à l’éditeur de code. Elle repère des erreurs qui échappent à l’analyse statique classique, comme un nom de route mal orthographié ou un gabarit absent, en amorçant réellement l’application. Livrée avec la CLI Symfony 5.20, elle s’adresse autant aux équipes qu’aux agents de code chargés de valider leurs propres modifications avant relecture.
Le problème : des chaînes qui ont un sens pour Symfony
Une application Symfony est constellée de chaînes de caractères porteuses de sens : noms de routes, chemins de gabarits, clés de traduction, identifiants de services, clés de configuration. Pour PHP, ce sont des chaînes comme les autres, qu’aucun typage ne vient valider.
« Une application Symfony est pleine de chaînes qui signifient quelque chose. Pour PHP, ce sont des chaînes comme les autres. »
Résultat : une route renommée mais oubliée dans un contrôleur, une clé de traduction absente ou un gabarit supprimé passent la compilation et les vérifications de type, puis cassent à l’exécution. C’est précisément cet angle mort que la commande cible.
Ce que la commande vérifie
Le vérificateur couvre 30 codes de diagnostic répartis par domaine. La liste complète s’affiche avec symfony lsp:check --list-codes.
| Domaine | Exemples de détections |
|---|---|
| Routes | Route inconnue, paramètre requis manquant |
| Gabarits & Twig | Template absent, composant ou argument de filtre inconnu |
| Traductions | Clé, domaine ou paramètre de message manquant |
| Services & configuration | Service ou paramètre inconnu, clé ou type de bundle invalide |
| Messenger | Bus ou transport inconnu, signature de handler invalide |
| Sécurité & formulaires | Firewall ou fournisseur d’utilisateurs inconnu, option de formulaire invalide |
Analyse à l’exécution et sorties pour la CI
L’analyse à l’exécution est active par défaut : le vérificateur amorce l’application dans l’environnement Symfony choisi et charge les mêmes métadonnées que les intégrations d’éditeur, de sorte que les diagnostics reflètent l’application réelle et non une supposition fondée sur des conventions. Pour les chaînes d’intégration continue qui ne doivent exécuter aucun code applicatif, le mode --source-only reste disponible.
# Vérifier l'ensemble du projet
symfony lsp:check
# Restreindre à des dossiers ou motifs
symfony lsp:check src/ templates/
symfony lsp:check 'config/**/*.yaml'
# Sans exécuter le code applicatif
symfony lsp:check --source-onlyTrois formats structurés facilitent l’intégration : JSON, annotations GitHub Actions et SARIF 2.1 pour les systèmes d’analyse de code. Les codes de sortie distinguent l’absence de diagnostic bloquant (0), la présence de diagnostics bloquants (10), l’invocation invalide (11) et l’analyse incomplète (12).
# .github/workflows/symfony-diagnostics.yaml
name: Symfony diagnostics
on: [push, pull_request]
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: shivammathur/setup-php@v2
with:
php-version: '8.4'
tools: symfony-cli
- run: composer install --no-progress
- run: symfony lsp:check --format=githubAdoption progressive : baseline et politique de blocage
Une base de référence permet d’introduire la commande sur un projet existant sans bloquer immédiatement la chaîne. Les diagnostics déjà présents deviennent non bloquants, tout en restant visibles, et survivent aux déplacements de lignes sans rapport.
# Générer la base de référence
symfony lsp:check --generate-baseline
# La réutiliser ensuite
symfony lsp:check --baseline=.symfony-lsp-baseline.json
# Ne bloquer que sur certains codes
symfony lsp:check --fail-on=route.not_found,translation.not_foundPoint de vigilance. En mode par défaut, la commande amorce l’application dans la CI : elle a donc besoin des variables d’environnement et des services attendus au démarrage. Sur un environnement restreint, --source-only évite l’exécution mais réduit la finesse de l’analyse. En cas d’échec d’indexation ou de dépassement de délai, le rapport est marqué comme incomplet plutôt que silencieusement dégradé.
Ce qu’il faut retenir
La commande symfony lsp:check transporte dans la CI une catégorie d’erreurs jusqu’ici détectées à l’exécution ou en production. En bootant l’application, elle valide les liens propres à Symfony que ni le typage ni l’analyse statique ne couvrent. Les sorties SARIF et GitHub, les bases de référence et le mode source-only en font un outil prêt pour les pipelines, y compris ceux pilotés par des agents de code.
Sur mes projets Symfony, les erreurs les plus vicieuses ne sont presque jamais des erreurs de type : ce sont des routes renommées à moitié et des clés de traduction fantômes, invisibles jusqu’à la démo client. Une commande qui les attrape en CI répond à un vrai besoin, et je vais l’intégrer sur au moins un pipeline dès cette semaine. Mon seul réflexe de prudence : commencer avec une baseline sur les projets anciens, sous peine de rendre la CI rouge dès le premier passage. — Simon Janvier
Pour aller plus loin
Introducing symfony lsp:check: Symfony-Aware Diagnostics in Your CI (Symfony Blog)
