Symfony vérifie vos routes dans la CI

Ce qui se passe

Les Symfony Language Tools sortent de l'éditeur. La commande symfony lsp:check exécute en ligne de commande les diagnostics jusqu'ici réservés aux intégrations PhpStorm et VS Code, et fonctionne sur n'importe quelle application Symfony, que l'équipe utilise ou non ces intégrations.

Le trou qu'elle comble est précis. Une application Symfony est pleine de chaînes qui désignent quelque chose : noms de routes, chemins de templates, clés de traduction, identifiants de services, clés de configuration de bundle. Pour PHP, ce sont des chaînes ordinaires. PHPStan et Psalm travaillent au niveau des types et à l'intérieur des fichiers PHP ; même l'extension Symfony de PHPStan, qui rend l'analyse consciente du conteneur, ne va pas voir dans les templates, les traductions ou les fichiers de configuration.

symfony lsp:check
symfony lsp:check src/ templates/
symfony lsp:check 'config/**/*.yaml'
symfony lsp:check --list-codes

Pourquoi ça compte

Il faut Symfony CLI 5.20.0 ou plus récent ; le binaire symfony-lsp des GitHub Releases accepte les mêmes options. Trente codes de diagnostic sont disponibles : routes inconnues et paramètres de route manquants, templates et composants Twig absents, arguments inconnus de fonctions et filtres Twig, clés, domaines et placeholders de traduction, services et paramètres, noms d'arguments et d'options de console, clés et types de configuration de bundle, processeurs de variables d'environnement, bus et transports Messenger, options de contraintes de validation, contrôleurs Stimulus et entrées d'importmap, firewalls et user providers, options de formulaire et méthodes de listeners.

L'analyse runtime est active par défaut : le checker démarre l'application dans l'environnement sélectionné et charge les vraies routes, services et configurations. Un job qui ne doit exécuter aucun code applicatif passe --source-only. Un échec de runtime ou d'indexation marque le rapport incomplete au lieu de retomber en silence sur l'analyse de surface.

Comment s'y prendre

Trois formats structurés sortent du même appel : --format=json, --format=github (annotations posées sur les fichiers et les lignes) et --format=sarif (SARIF 2.1, empreintes stables, exploitable par un code scanning).

# .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=github

Sur une application existante, la baseline évite le mur du premier jour : les occurrences connues restent visibles sans bloquer, survivent aux déplacements de lignes, et se rafraîchissent avec --refresh-baseline (ou --strict-baseline pour exiger le retrait des entrées périmées). Le fichier de configuration .symfony-lsp.json est partagé avec les intégrations éditeur ; les diagnostics de traduction manquante y sont opt-in.

Source : Symfony — Introducing symfony lsp:check: Symfony-Aware Diagnostics in Your CI