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.yamlinizia conframework:).
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 mailernon funziona più; usa invecedebug: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) eRouteLoaderInterface(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:
Altri articoli recenti
Laravel AI 1.1 e 1.2: Agent Skills, Cohere e structured output più solidi
Le release 1.1.0 e 1.2.0 di laravel/ai portano gli Agent Skills, l'approvazione obbligatoria per i tool built-in e nuovi provider come Cohere e Laya self-hosted. Sul fronte qualità arrivano i fix allo structured output per Bedrock e il supporto alle provider options. Aggiornati anche i modelli di default, con Claude 4.7+ che ignora i sampling params.
Laravel 13.35.0: scheduler più controllabile, code più flessibili e response Markdown
Laravel 13.35.0 porta Schedule::alwaysOnOneServer(), il supporto a schedule:interrupt per i comandi di lunga durata, --memory in percentuale per queue:work e il nuovo metodo markdown() sulla response factory. Tante piccole migliorie anche a test, view compilate in parallelo e dischi local.
BashBox: un interprete Bash in sandbox per agenti AI in PHP
BashBox è un interprete bash scritto in puro PHP che permette di eseguire gli script generati dagli agenti AI senza mai ricorrere a proc_open, exec o shell_exec. Ogni comando è una classe PHP che lavora su un filesystem virtuale, con limiti di esecuzione, quote disco e accesso di rete configurabili. Ideale per chi sviluppa agenti con il Laravel AI SDK o altre librerie simili.