Catorce archivos YAML en config/packages, y todos empiezan con la misma palabra. Los conté un jueves por la noche, cuando el mailer de staging se negaba a enviar nada. Antes de poder mirar siquiera el DSN tuve que bajar por framework:, luego por mailer: y por fin llegar al valor, en un archivo que ya se llama mailer.yaml. Symfony 8.2 convierte esa primera línea en opcional. Mi tesis es que deberías leer "opcional" como una forma educada de decir que tiene los días contados. Cuando subas a 8.2, borra el prefijo en ese mismo pull request. No esperes a que un aviso de deprecación te obligue.

config/packages/mailer.yaml
# old form, still accepted in Symfony 8.2 via aliases
framework:
  mailer:
    dsn: '%env(MAILER_DSN)%'

# new form, owned by MailerBundle
mailer:
  dsn: '%env(MAILER_DSN)%'

Los hechos caben en poco. En 8.2, 29 componentes que antes se configuraban dentro de FrameworkBundle traen ahora su propio bundle, y este se registra solo en cuanto instalas el componente, así que config/bundles.php no se toca. Cada bundle saca su clave raíz del nombre de la clase: MailerBundle responde a mailer, PropertyInfoBundle a property_info. FrameworkBundle se queda con lo que de verdad pertenece a la capa HTTP, como las sesiones, CSRF, el profiler y los fragments. Para quienes mantienen el framework, esta es la gran noticia: una opción nueva de Mailer ya es un cambio en symfony/mailer y en ningún otro sitio. Para los que solo escribimos configuración, lo que se nota es el vocabulario.

Y es justo en el vocabulario donde creo que esta versión nos pide algo sin decirlo en voz alta. Las claves antiguas siguen funcionando porque FrameworkBundle las declara con un nuevo NodeDefinition::aliasOf() y las reenvía a la extensión del componente antes de que se cargue nada. Es elegante. Pero las herramientas ya se han pasado a los nombres nuevos. Si quieres ver la configuración efectiva de tu cliente HTTP, ahora ejecutas debug:config http_client. La ruta con framework ya no existe en ese comando. Además, tres raíces cambiaron de nombre por el camino: assets pasó a asset, translator a translation y workflows a workflow. Un código que sigue usando la forma antigua dice una cosa en sus archivos mientras la consola dice otra.

Aquí va el mejor argumento en mi contra, y es bueno. El equipo de Symfony eligió alias en vez de deprecaciones precisamente para que nadie tuviera que tocar una configuración que funciona. Un diff que quita un nivel de sangría de cada archivo de paquete no le aporta nada a ningún usuario. Choca con cada rama abierta que toque la configuración y le pone a quien revisa cuarenta líneas de ruido de espacios en blanco para aprobar a ciegas. Si tu equipo lleva un puñado de aplicaciones y actualiza según calendario, dejar framework: tal cual es una forma razonable de aprovechar la tarde. Yo mismo he tomado esa decisión con cosas menos importantes.

Aun así me quedo en el otro lado, porque el único cambio real de comportamiento de esta versión demuestra por qué importa que la estructura sea honesta. Con la antigua extensión única, activar Forms activaba también Validation, simplemente por dónde estaba el código que los registraba. En 8.2 cada componente decide por su cuenta, y Validation aparece porque symfony/validator está instalado, no porque Forms lo haya invitado. La mayoría de las aplicaciones con formularios ya tienen el validador, así que no se rompe nada. Pero la lección va de legibilidad. El framework ha eliminado un acoplamiento que solo podías descubrir leyendo el código. Tu configuración debería dejar de fingir que ese acoplamiento sigue ahí.

También hay un motivo práctico, y tiene que ver con el momento. El PR de la actualización es la única ocasión en la que todo el mundo espera que config/packages cambie. Quien revisa ya está mirando ahí, la CI ya está pasando la suite completa y git blame atribuirá el cambio de nombres a un commit llamado "Symfony 8.2", que dentro de un año se explicará solo. Si lo haces seis meses después como limpieza aparte, es un diff misterioso de alguien que, por lo visto, tuvo una semana tranquila. Si no lo haces nunca, la próxima persona que contrates aprenderá en tu repo dos nombres para el mismo ajuste. De un modo u otro acabas pagando, y pagar tarde sale más caro.

Reconozco que la división me entusiasma más en los workers que en la parte web. Un consumidor de Messenger no necesita sesiones ni profiler, y ahora no tiene por qué cargar con ellos. Registras ConsoleBundle y los bundles de los componentes que el worker usa de verdad. Los bundles sin trabajo en tiempo de ejecución se quedan además como simples nombres de clase hasta que algo los pide, y MimeBundle es la excepción deliberada, porque sus tipos MIME por defecto hay que fijarlos en cada petición. A mis amigos que escriben Go les encanta presumir de lo pequeños que son sus binarios. Un worker de Symfony que arranca solo lo que usa es una buena respuesta, y no por eso es menos PHP.

Así que mi regla es que la actualización y el cambio de nombres salgan juntos, con un commit para cada cosa para que quien revise pueda pasar rápido por el segundo. Sé que es una cuestión de criterio, y algunos gestionáis flotas de aplicaciones donde tocar la configuración tiene un coste real. Si mantienes framework: a propósito, me gustaría saber qué te haría cambiar de opinión. ¿Haría falta una deprecación de verdad en una versión futura, o hay algún motivo para que los alias vivan para siempre que yo no estoy viendo?