Quatorze fichiers YAML dans config/packages, et tous commencent par le même mot. Je les ai comptés un jeudi soir, pendant que le mailer de staging refusait d'envoyer quoi que ce soit. Avant même de pouvoir regarder le DSN, il fallait que je descende à travers framework:, puis mailer:, puis enfin la valeur, dans un fichier qui s'appelle déjà mailer.yaml. Symfony 8.2 rend cette première ligne facultative. Ma thèse : prends « facultatif » comme une façon polie de dire que c'est sur le départ. Quand tu passes en 8.2, supprime le préfixe dans cette même pull request. N'attends pas qu'un avertissement de dépréciation t'y oblige.

# 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)%'

Les faits sont vite dits. En 8.2, 29 composants qui se configuraient jusqu'ici dans FrameworkBundle livrent désormais leur propre bundle, et celui-ci s'enregistre tout seul dès que le composant est installé, donc config/bundles.php reste intact. Chaque bundle tire sa clé racine du nom de sa classe : MailerBundle répond à mailer, PropertyInfoBundle à property_info. FrameworkBundle garde ce qui relève vraiment de la couche HTTP, comme les sessions, le CSRF, le profiler et les fragments. Pour les mainteneurs, c'est la grande nouvelle : une nouvelle option de Mailer, c'est désormais une modification de symfony/mailer et de rien d'autre. Pour ceux d'entre nous qui se contentent d'écrire de la config, le changement visible, c'est le vocabulaire.

Et c'est justement dans ce vocabulaire que la version nous demande discrètement quelque chose, à mon avis. Les anciennes clés continuent de marcher parce que FrameworkBundle les déclare avec un nouveau NodeDefinition::aliasOf() et les transmet à l'extension du composant avant que quoi que ce soit ne se charge. C'est élégant. Mais l'outillage est déjà passé aux nouveaux noms. Si tu veux voir les réglages effectifs de ton client HTTP, tu lances maintenant debug:config http_client. Le chemin framework a disparu de cette commande. Trois racines ont aussi changé d'orthographe au passage : assets est devenu asset, translator est devenu translation, workflows est devenu workflow. Une base de code qui écrit encore l'ancienne forme dit désormais une chose dans ses fichiers pendant que la console en dit une autre.

Voici le meilleur argument contre moi, et il est solide. L'équipe Symfony a choisi les alias plutôt que la dépréciation précisément pour que personne n'ait à toucher une config qui marche. Un diff qui retire un niveau d'indentation dans chaque fichier de package n'apporte rien à aucun utilisateur. Il entre en conflit avec toutes les branches ouvertes qui touchent à la config, et il demande à un relecteur d'approuver les yeux fermés quarante lignes de bruit d'indentation. Si ton équipe gère une poignée d'applis et fait ses mises à jour selon un calendrier, laisser framework: tranquille est une façon défendable d'occuper ton après-midi. J'ai moi-même fait ce choix sur des sujets moins importants.

Je penche quand même de l'autre côté, parce que le seul vrai changement de comportement de cette version montre pourquoi une structure honnête compte. Avec l'ancienne extension unique, activer Forms activait aussi Validation, simplement à cause de l'endroit où se trouvait le code qui les enregistrait. En 8.2, chaque composant décide pour lui-même, et Validation apparaît parce que symfony/validator est installé, pas parce que Forms l'a invité. La plupart des applis qui utilisent des formulaires ont de toute façon le validator, donc rien ne casse. Mais la leçon porte sur la lisibilité. Le framework a supprimé un couplage qu'on ne pouvait découvrir qu'en lisant le code. Ta config devrait arrêter de faire comme si ce couplage existait encore.

Il y a aussi une raison pratique, et c'est une question de timing. La PR de mise à jour est le seul moment où tout le monde s'attend à ce que config/packages bouge. Les relecteurs regardent déjà par là, la CI fait déjà tourner toute la suite, et git blame rattachera le renommage à un commit intitulé « Symfony 8.2 », qui s'expliquera tout seul dans un an. Fais-le six mois plus tard comme petit ménage isolé, et ça devient un diff mystère signé par quelqu'un qui avait visiblement une semaine calme. Ne le fais jamais, et la prochaine recrue apprendra dans ton dépôt deux orthographes pour le même réglage. Dans tous les cas tu finis par payer, et payer plus tard coûte plus cher.

J'avoue que ce découpage m'enthousiasme davantage côté workers que côté web. Un consumer Messenger n'a que faire des sessions ou d'un profiler, et maintenant il n'est plus obligé de les embarquer. Tu enregistres ConsoleBundle et les bundles de composants que le worker utilise vraiment. Les bundles sans travail à l'exécution restent par ailleurs de simples noms de classe tant que personne ne les réclame, et MimeBundle est l'exception assumée, parce que ses types MIME par défaut doivent être définis à chaque requête. Mes amis qui écrivent du Go adorent rappeler à quel point leurs binaires sont légers. Un worker Symfony qui ne démarre que ce qu'il utilise, c'est une réponse honnête, et ça reste du PHP pur jus.

Ma règle, donc : la montée de version et le renommage partent ensemble, avec un commit pour chacun pour que le relecteur puisse survoler le second. Je sais que c'est une question de jugement, et certains gèrent des flottes entières d'applis où chaque changement de config a un vrai coût. Si tu gardes framework: exprès, j'aimerais savoir ce qui te ferait changer d'avis. Faudrait-il une vraie dépréciation dans une version ultérieure, ou existe-t-il une raison de garder les alias pour toujours que je ne vois pas ?