Symfony lsp:check bringt Framework-Diagnosen in die Continuous Integration

Am 31. August 2026 angekündigt, wiederholt der Befehl symfony lsp:check in der Continuous Integration die Diagnosen, die bislang dem Code-Editor vorbehalten waren. Er erkennt Fehler, die der klassischen statischen Analyse entgehen, etwa einen falsch geschriebenen Routennamen oder ein fehlendes Template, indem er die Anwendung tatsächlich startet. Ausgeliefert mit der Symfony-CLI 5.20, richtet er sich ebenso an Teams wie an Coding-Agenten, die ihre eigenen Änderungen vor dem Review prüfen sollen.

#Das Problem: Zeichenketten, die für Symfony etwas bedeuten

Eine Symfony-Anwendung ist übersät mit bedeutungstragenden Zeichenketten: Routennamen, Template-Pfade, Übersetzungsschlüssel, Service-Bezeichner, Konfigurationsschlüssel. Für PHP sind es Zeichenketten wie alle anderen, die kein Typsystem validiert.

„Eine Symfony-Anwendung ist voll von Zeichenketten, die etwas bedeuten. Für PHP sind es Zeichenketten wie alle anderen.“

Die Folge: eine umbenannte, aber in einem Controller vergessene Route, ein fehlender Übersetzungsschlüssel oder ein gelöschtes Template bestehen Kompilierung und Typprüfung und brechen dann zur Laufzeit. Genau diesen blinden Fleck nimmt der Befehl ins Visier.

#Was der Befehl prüft

Der Prüfer deckt 30 Diagnosecodes ab, nach Bereichen gruppiert. Die vollständige Liste zeigt symfony lsp:check --list-codes.

#Laufzeitanalyse und CI-taugliche Ausgaben

Die Laufzeitanalyse ist standardmäßig aktiv: Der Prüfer startet die Anwendung in der gewählten Symfony-Umgebung und lädt dieselben Metadaten wie die Editor-Integrationen, sodass die Diagnosen die echte Anwendung widerspiegeln und keine auf Konventionen beruhende Vermutung. Für CI-Jobs, die keinen Anwendungscode ausführen dürfen, steht der Modus --source-only bereit.

# Das gesamte Projekt pruefen
symfony lsp:check

# Auf Verzeichnisse oder Muster eingrenzen
symfony lsp:check src/ templates/
symfony lsp:check 'config/**/*.yaml'

# Ohne Ausfuehrung des Anwendungscodes
symfony lsp:check --source-only

Drei strukturierte Formate erleichtern die Integration: JSON, GitHub-Actions-Annotationen und SARIF 2.1 für Code-Scanning-Systeme. Die Exit-Codes unterscheiden das Fehlen blockierender Diagnosen (0), das Vorhandensein blockierender Diagnosen (10), einen ungültigen Aufruf (11) und eine unvollständige Analyse (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=github

#Schrittweise Einführung: Baseline und Blockierungsrichtlinie

Eine Baseline erlaubt es, den Befehl auf einem bestehenden Projekt einzuführen, ohne die Pipeline sofort zu blockieren. Bereits vorhandene Diagnosen werden nicht blockierend, bleiben aber sichtbar, und sie überstehen unabhängige Zeilenverschiebungen.

# Die Baseline erzeugen
symfony lsp:check --generate-baseline

# Sie anschliessend wiederverwenden
symfony lsp:check --baseline=.symfony-lsp-baseline.json

# Nur bei bestimmten Codes blockieren
symfony lsp:check --fail-on=route.not_found,translation.not_found

#Das Wichtigste in Kürze

Der Befehl symfony lsp:check bringt eine Klasse von Fehlern in die CI, die bisher zur Laufzeit oder in Produktion auffielen. Indem er die Anwendung startet, validiert er die Symfony-eigenen Verknüpfungen, die weder Typisierung noch statische Analyse abdecken. SARIF- und GitHub-Ausgabe, Baselines und der Source-only-Modus machen ihn zu einem pipelinetauglichen Werkzeug, auch für von Coding-Agenten gesteuerte Pipelines.

#Weiterführend

Introducing symfony lsp:check: Symfony-Aware Diagnostics in Your CI (Symfony Blog)