The Php Times

En 2021 convertí el proyecto de un cliente a los config builders fluidos que llegaron con Symfony 5.3. Cadenas de métodos, autocompletado, la experiencia SecurityConfig completa. Parecía la forma adulta de configurar un framework. Cuatro años después ese formato está marcado como obsoleto en 7.4 y ha desaparecido del camino recomendado, y mi primera reacción fue un largo suspiro frente al escritorio. Mi segunda reacción, después de leer de verdad el razonamiento, fue que Symfony está haciendo lo correcto, y quiero defender esa postura aunque me haya costado una tarde de trabajo de migración.

Primero los hechos. Symfony 8.0 salió el 27 de noviembre de 2025, en paralelo con la LTS 7.4. La misma base de código, menos todo lo que 7.4 declaró obsoleto. Eso incluye el XmlFileLoader tanto para definiciones de servicios como para rutas, deprecado mediante el PR #60568 de Mathieu Lechat en octubre de 2025 y ahora simplemente ausente. Si tu aplicación, o cualquier bundle de tu directorio vendor, todavía depende de que se cargue un services.xml o un routes.xml, no arrancará en 8.0. YAML, mientras tanto, está explícitamente a salvo: el equipo central ha dicho que su deprecación no está planeada, y las recipes lo siguen generando por defecto.

Este es el argumento que quiero plantear: durante veinte años tratamos el formato de configuración como una cuestión de gusto, y ese enfoque siempre estuvo ligeramente equivocado. La pregunta real es qué pueden verificar tus herramientas antes de que compile el contenedor. XML tenía un schema, claro, pero el ecosistema nunca construyó soporte moderno de editor a su alrededor, y Flex nunca lo escribió. Los builders fluidos parecían amigables para el desarrollador, pero Nicolas Grekas explicó el fallo fatal: encierran cada árbol de configuración en una única forma canónica, lo que hace imposibles las actualizaciones automáticas de recipes. Un formato que pelea contra tu gestor de paquetes pierde, por muy bien que se lea.

Lo que reemplaza a ambos es revelador. El nuevo formato PHP son arrays planos envueltos en App::config() o Routes::config(), y el truco es que Symfony genera metadatos de array shapes en un archivo config/reference.php que PHPStan, Psalm y PhpStorm pueden consumir. Tu configuración se convierte en algo que un analizador estático puede revisar en busca de claves incorrectas antes de que llegues a ejecutar cache:clear en staging. YAML recibió el mismo tratamiento desde otro ángulo: 7.4 añade schemas JSON para los archivos de servicios, rutas, validación y serializer, referenciados mediante un comentario de yaml-language-server que los editores reconocen. Dos formatos, ambos verificables por máquina. Eso es convergencia, no churn.

Ahora la concesión honesta, porque hay una de verdad. XML fue durante años el formato oficialmente recomendado para autores de bundles, y muchos paquetes más o menos mantenidos todavía distribuyen su cableado interno como Resources/config/services.xml. Esos bundles no se degradan con elegancia en 8.0, dejan de funcionar por completo. Y los builders fluidos duraron cuatro años desde su introducción hasta su deprecación, que es exactamente el tipo de vida útil que hace dudar a los equipos antes de adoptar cualquier novedad del framework. El archivo reference.php también tiene sus aristas: cambia con cada modificación de dependencias, así que tus pull requests acumulan diffs ruidosos, y al menos un usuario se encontró con una generación rota por un glob como **/*.graphql en un valor de configuración. Nada de esto es gratis.

Aun así me quedo donde me quedo, por dos razones. Primera, a nadie lo están empujando por un precipicio. La LTS 7.4 trae cuatro años de soporte de seguridad, ejecuta los formatos viejos y nuevos en paralelo, y te da un registro de deprecaciones que realmente puedes ir resolviendo. Existe un conversor comunitario en github.com/GromNaN/symfony-config-xml-to-php que reescribe el XML de bundles al formato de arrays, y enviar su salida upstream como PR es una forma genuinamente útil de invertir una hora. Segunda, Symfony está siendo inusualmente franco sobre su propio calendario: el blog dice sin rodeos que el formato de arrays todavía no es el predeterminado recomendado, porque el soporte de editor para array shapes complejos es desigual y Flex sigue hablando solo YAML. Un framework que dice "esta es la dirección, pero no saltes todavía" ha recuperado algo de confianza tras el episodio de los builders fluidos, al menos en mi opinión.

Así que mi consejo práctico se aparta del entusiasmo por los formatos en ambas direcciones. Deja en paz tu YAML que funciona, añade los comentarios de schema, disfruta del autocompletado. Escribe la configuración genuinamente nueva en el formato de arrays si tu equipo ya ejecuta PHPStan de todos modos, porque ahí está la palanca. Y antes siquiera de crear la rama para 8.0, haz grep en tu directorio vendor buscando configuración XML, porque el bundle que olvidaste en 2019 es lo que de verdad te va a bloquear. Lo que me deja con la pregunta a la que sigo dando vueltas: cuando el formato de arrays madure y Flex aprenda a escribirlo, ¿se convierte YAML silenciosamente en legacy dentro de cinco años, o un formato legible por humanos con validación de schema es sencillamente el mejor estado final para la configuración de aplicaciones? He cambiado de opinión dos veces esta semana. Cuéntame dónde te posicionas tú.