Anunciado el 31 de agosto de 2026, el comando symfony lsp:check reproduce dentro de la integración continua los diagnósticos hasta ahora reservados al editor de código. Detecta errores que escapan al análisis estático clásico, como un nombre de ruta mal escrito o una plantilla ausente, arrancando realmente la aplicación. Incluido en la CLI de Symfony 5.20, se dirige tanto a los equipos como a los agentes de código encargados de validar sus propios cambios antes de la revisión.
El problema: cadenas que significan algo para Symfony
Una aplicación Symfony está sembrada de cadenas con significado: nombres de rutas, rutas de plantillas, claves de traducción, identificadores de servicios, claves de configuración. Para PHP son cadenas como cualquier otra, que ningún tipado valida.
«Una aplicación Symfony está llena de cadenas que significan algo. Para PHP son cadenas como cualquier otra.»
El resultado: una ruta renombrada pero olvidada en un controlador, una clave de traducción ausente o una plantilla eliminada superan la compilación y las comprobaciones de tipo, y luego fallan en ejecución. Ese es exactamente el punto ciego que ataca el comando.
Qué verifica el comando
El verificador cubre 30 códigos de diagnóstico agrupados por dominio. La lista completa se muestra con symfony lsp:check --list-codes.
| Dominio | Ejemplos de detección |
|---|---|
| Rutas | Ruta inexistente, parámetro obligatorio ausente |
| Plantillas y Twig | Plantilla ausente, componente o argumento de filtro desconocido |
| Traducciones | Clave, dominio o marcador de mensaje ausente |
| Servicios y configuración | Servicio o parámetro desconocido, clave o tipo de bundle inválido |
| Messenger | Bus o transporte desconocido, firma de handler inválida |
| Seguridad y formularios | Firewall o proveedor de usuarios desconocido, opción de formulario inválida |
Análisis en ejecución y salidas para la CI
El análisis en ejecución está activo por defecto: el verificador arranca la aplicación en el entorno Symfony elegido y carga los mismos metadatos que las integraciones del editor, de modo que los diagnósticos reflejan la aplicación real y no una suposición basada en convenciones. Para los trabajos de integración continua que no deben ejecutar ningún código de la aplicación, el modo --source-only está disponible.
# Verificar todo el proyecto
symfony lsp:check
# Limitar a carpetas o patrones
symfony lsp:check src/ templates/
symfony lsp:check 'config/**/*.yaml'
# Sin ejecutar el código de la aplicación
symfony lsp:check --source-onlyTres formatos estructurados facilitan la integración: JSON, anotaciones de GitHub Actions y SARIF 2.1 para los sistemas de análisis de código. Los códigos de salida distinguen la ausencia de diagnósticos bloqueantes (0), la presencia de diagnósticos bloqueantes (10), la invocación inválida (11) y el análisis incompleto (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=githubAdopción progresiva: baseline y política de bloqueo
Una línea base permite introducir el comando en un proyecto existente sin bloquear la cadena de inmediato. Los diagnósticos ya presentes se vuelven no bloqueantes, sin dejar de ser visibles, y sobreviven a los desplazamientos de líneas ajenos.
# Generar la línea base
symfony lsp:check --generate-baseline
# Reutilizarla después
symfony lsp:check --baseline=.symfony-lsp-baseline.json
# Bloquear solo en códigos concretos
symfony lsp:check --fail-on=route.not_found,translation.not_foundPunto de atención. En su modo por defecto, el comando arranca la aplicación dentro de la CI: necesita, por tanto, las variables de entorno y los servicios esperados al iniciar. En un entorno restringido, --source-only evita la ejecución pero reduce la finura del análisis. Ante un fallo de indexación o un tiempo de espera agotado, el informe se marca como incompleto en lugar de degradarse en silencio.
Lo que hay que recordar
El comando symfony lsp:check traslada a la CI una categoría de errores que antes se detectaban en ejecución o en producción. Al arrancar la aplicación, valida los enlaces propios de Symfony que ni el tipado ni el análisis estático cubren. Las salidas SARIF y GitHub, las líneas base y el modo source-only lo convierten en una herramienta lista para los pipelines, incluidos los pilotados por agentes de código.
En mis proyectos Symfony, los errores más traicioneros casi nunca son de tipo: son rutas renombradas a medias y claves de traducción fantasma, invisibles hasta la demo con el cliente. Un comando que los atrapa en la CI responde a una necesidad real, y voy a integrarlo en al menos un pipeline esta misma semana. Mi único reflejo de prudencia: empezar con una línea base en los proyectos antiguos, o la CI se pondrá roja en la primera pasada. — Simon Janvier
Para profundizar
Introducing symfony lsp:check: Symfony-Aware Diagnostics in Your CI (Symfony Blog)
