notiziephp.it

Novità in Symfony 8.2: un bundle per componente (Symfony Blog)

Traduzione da Symfony Blog
18 Settembre 2026 Tempo di lettura: 3 minuti
Novità in Symfony 8.2: un bundle per componente (Symfony Blog)

FrameworkBundle è il collante tra i componenti di Symfony e le applicazioni Symfony. Nel corso degli anni lo abbiamo usato per definire la configurazione e i servizi della maggior parte dei componenti. Questo ha causato alcuni problemi:

  • Aggiungere una funzionalità a un componente (ad es. una nuova opzione del mailer) richiedeva modifiche sia al componente sia a FrameworkBundle;
  • Alcune sezioni dipendevano da altre in modi non ovvi (ad es. abilitare i form abilitava anche la validation);
  • I file di configurazione avevano un livello root superfluo (ad es. la configurazione in config/packages/mailer.yaml inizia con framework:).

In Symfony 8.2, ogni componente include il proprio bundle con la sua configurazione, i suoi servizi e le classi correlate. Ci sono 29 nuovi bundle come CacheBundle, HttpClientBundle, MailerBundle, MessengerBundle, ecc.

Non devi cambiare nulla. I nuovi bundle vengono registrati automaticamente quando il loro componente è installato, quindi non c'è nulla da aggiungere a config/bundles.php. Grazie a una nuova funzionalità di aliasing della configurazione, tutte le tue chiavi framework.* esistenti (framework.mailer, framework.messenger, ecc.) continuano a funzionare esattamente come prima e nulla è deprecato.

Tuttavia, se preferisci, ora puoi rimuovere il livello framework da questi file di configurazione:

Lo stesso vale nei file di configurazione PHP:

La maggior parte delle chiavi mantiene il proprio nome a livello root, tranne queste: framework.assets ora è asset, framework.translator ora è translation e framework.workflows ora è workflow.

Anche le chiavi lock e semaphore accettano direttamente un DSN, come scorciatoia per la loro opzione resources (in precedenza, un valore stringa a livello root veniva ignorato silenziosamente):

Altre modifiche minori che potresti notare:

  • debug:config framework mailer non funziona più; usa invece debug:config mailer;
  • Abilitare i form non abilita più automaticamente la validation; lo fa l'installazione di symfony/validator;
  • Alcune classi si sono spostate da FrameworkBundle ai loro componenti e quelle vecchie sono deprecate. Quelle che più probabilmente userai nelle tue app sono RedirectController (ora nel componente Routing), TemplateController (ora in TwigBundle), AsRoutingConditionService (ora nel componente Routing) e RouteLoaderInterface (sostituita dall'attributo #[AsRouteLoader] del componente Routing).

Registrare 29 bundle in più non rallenta le tue app. La maggior parte di questi bundle è necessaria solo durante la compilazione del container, quindi in produzione Symfony non crea più i loro oggetti a ogni richiesta (lo fa solo quando del codice li richiede).

Questo lavoro ha richiesto alcune nuove funzionalità nel componente Config che puoi usare anche nei tuoi bundle. Il metodo aliasOf() fa sì che un nodo di livello root inoltri il suo valore alla configurazione di un'altra extension. È così che framework.workflows continua a funzionare mentre il componente Workflow ora possiede la configurazione workflow:

Il nuovo metodo appendFromCallback() ti permette di aggiungere diversi nodi da una callback senza rompere la catena fluente del tree builder. Questo è utile quando lo stesso gruppo di opzioni si ripete in parti diverse della tua configurazione:

Condividi su: LinkedIn

Altri articoli recenti