Laravel 12: struttura app e novità rispetto alle versioni precedenti

Hai appena lanciato laravel new progetto e ti trovi una struttura app quasi vuota. Niente Http/Kernel.php, niente Console/Kernel.php, nessuna traccia di Providers/RouteServiceProvider. Se arrivi da Laravel 10 o più indietro, è normale sentirsi persi. Ma non preoccuparti: questa pulizia è una buona notizia. Noi di Meteora Web abbiamo passato mesi a migrare decine di progetti dalla vecchia struttura a quella nuova, e possiamo dirti che il risultato è più manutenibile, più veloce da configurare e meno rumoroso. In questa guida ti spieghiamo esattamente cosa cambia in Laravel 12 rispetto alle versioni precedenti, come funziona il nuovo bootstrap/app.php e come adattare le tue abitudini.

Perché Laravel ha rivoluzionato la struttura dell'app

Il framework è cresciuto. Con ogni versione, Laravel ha accumulato file di configurazione, provider e classi che molti sviluppatori non toccavano mai. Laravel 11 ha fatto piazza pulita: ha spostato quasi tutta la logica di boot nel nuovo file bootstrap/app.php e ha rimosso i file che venivano creati di default ma lasciati invariati. Laravel 12 eredita e rafforza questa filosofia. Il risultato? Meno file da gestire, meno confusione e una curva di apprendimento più rapida per i nuovi arrivati. Per noi, che veniamo dalla contabilità e dai bilanci, è come passare da un registro contabile pieno di voci superflue a un estratto conto pulito: conta la sostanza.

Le differenze chiave rispetto a Laravel 10 e precedenti

1. Addio a Http/Kernel e Console/Kernel

In Laravel 10, ogni richiesta passava attraverso app/Http/Kernel.php che gestiva middleware globali, gruppi di middleware e priorità. In Laravel 12, tutto questo è centralizzato in bootstrap/app.php. Lo stesso vale per app/Console/Kernel.php: i comandi Artisan e la pianificazione vengono ora configurati direttamente nel bootstrap o tramite tratti nei comandi stessi.

// Laravel 12 – bootstrap/app.php
return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        api: __DIR__.'/../routes/api.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->web(prepend: [
            \App\Http\Middleware\ForceJson::class,
        ]);
        $middleware->api(remove: [
            \Illuminate\Routing\Middleware\ThrottleRequests::class,
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

Questa scrittura è più dichiarativa. Puoi aggiungere middleware globali, gruppi personalizzati e alias direttamente nel file che già conosci. Nessun file Kernel separato da cercare.

2. Service Providers ridotti all’osso

Prima, ogni nuovo progetto includeva AppServiceProvider, AuthServiceProvider, BroadcastServiceProvider, EventServiceProvider e RouteServiceProvider. In Laravel 12, la maggior parte questi provider sono spariti di default. Rimane solo AppServiceProvider (vuoto) e RouteServiceProvider non esiste più: le rotte si registrano nell’array withRouting di bootstrap/app.php. Eventi e listener si configurano nel nuovo array discoverEvents o nel metodo boot del provider. Noi adoriamo questa semplificazione: meno codice boilerplate da mantenere.

3. Migrazioni e factory più snelle

Le migrazioni di default ora includono solo create_users_table e create_personal_access_tokens_table. Le tabelle password_resets, failed_jobs e job_batches non vengono più create automaticamente. Se ti servono, basta eseguire php artisan make:migration con la flag appropriata. Le factory sono caricate automaticamente grazie alla discovery di Laravel 11/12, senza bisogno di registrare manualmente i percorsi.

4. La configurazione delle eccezioni è trasparente

Il vecchio App\Exceptions\Handler è scomparso. La gestione degli errori si configura direttamente nel metodo withExceptions di bootstrap/app.php. Questo rende immediatamente visibile cosa fai con le eccezioni, senza dover aprire un altro file. Esempio:

->withExceptions(function (Exceptions $exceptions) {
    $exceptions->report(function (CustomException $e) {
        // ...
    });
    $exceptions->render(function (CustomException $e) {
        return response()->json(['error' => $e->getMessage()], 400);
    });
})

5. Rotta /up predefinita per health check

Laravel 12 include una rotta di health check preconfigurata (/up) che restituisce un 200 OK se l’applicazione è attiva. Utile per bilanciatori di carico e monitoraggio. Nessuna configurazione extra: è già abilitata se usi withRouting con la chiave health.

Cosa resta uguale (e cosa cambia nella pratica)

Non tutto è stravolto. I controller vivono ancora in app/Http/Controllers, i model in app/Models, i comandi Artisan personalizzati in app/Console/Commands. Le viste in resources/views. Le rotte nei file routes/*. L’idea di base non cambia.

Ma la struttura di app è più piatta e leggera. Se stai avviando un progetto nuovo, non devi più cancellare file di default inutilizzati. Se stai migrando da Laravel 10, preparati a spostare la logica dei kernel e dei provider in bootstrap/app.php. Un consiglio pratico: non provare a forzare la vecchia struttura dentro la nuova. Piuttosto, prendi confidenza con il nuovo withMiddleware e withExceptions. Noi, di Meteora Web, abbiamo notato che lo sforzo iniziale di riadattamento paga in termini di pulizia del codice e facilità di debug.

Esempio pratico: aggiungere un middleware di autenticazione API su Laravel 12

In Laravel 10 avresti modificato app/Http/Kernel.php aggiungendo una riga nell’array $routeMiddleware. Oggi si fa così:

// bootstrap/app.php
use App\Http\Middleware\EnsureTokenIsValid;

->withMiddleware(function (Middleware $middleware) {
    $middleware->alias([
        'valid.token' => EnsureTokenIsValid::class,
    ]);
    $middleware->api(prepend: [
        EnsureTokenIsValid::class,
    ]);
})

Nota: gli alias sono registrati nello stesso punto, non in due file diversi. Tutto è centralizzato.

Gestire gli eventi in Laravel 12

In Laravel 10 dovevi creare EventServiceProvider e registrare eventi e listener nel metodo $listen. Ora puoi farlo in due modi: o usi la scoperta automatica degli eventi (default) oppure registri manualmente nel tuo AppServiceProvider. La scoperta automatica cerca eventi e listener in app/Events e app/Listeners. Puoi disabilitarla o personalizzarla in bootstrap/app.php:

'events' => [
    'discover' => true,
    'map' => [
        \App\Events\OrderShipped::class => [
            \App\Listeners\SendShipmentNotification::class,
            \App\Listeners\UpdateInventory::class,
        ],
    ],
],

Personalmente, preferiamo la mappatura manuale per progetti complessi: dà controllo e trasparenza.

Come aggiornare un progetto Laravel 10 a Laravel 12

Se hai un progetto legacy, il processo di upgrade è guidato da Laravel Shift o dalla documentazione ufficiale. I punti critici sono:

• Rimuovere i file superflui: elimina app/Http/Kernel.php, app/Console/Kernel.php, app/Exceptions/Handler.php, app/Providers/RouteServiceProvider.php e gli altri provider non più necessari.
• Spostare la configurazione: trasferisci middleware, alias, priorità e gruppi nel bootstrap/app.php.
• Rivedere le eccezioni: sposta la logica di report e render da Handler a withExceptions.
• Aggiornare i comandi: se usavi comandi pianificati, assicurati di registrarli ora nell’array withCommands o di usare il trait Schedule.

Noi consigliamo di testare ogni singolo step con una copia del progetto in locale. Abbiamo visto errori subdoli quando si dimenticano alias di middleware o binding di eccezioni.

Perché questa struttura è meglio anche per chi arriva da altri framework

Se vieni da Symfony o Node.js, troverai il nuovo bootstrap più familiare: tutto si riduce a un file centrale che orchestra middleware, routing e gestione errori. Non c’è più il doppio livello file-application. Laravel si allinea allo standard delle applicazioni moderne che usano un bootloader centralizzato (pensa a Vite o ad Angular). Questo riduce la frizione per i nuovi sviluppatori e rende il framework più accessibile.

In sintesi — cosa fare adesso

1. Crea un nuovo progetto Laravel 12: composer create-project laravel/laravel:^12.0 prova-laravel12 ed esplora la struttura.
2. Leggi il file bootstrap/app.php: commenta ogni metodo per capire a cosa serve. Prova ad aggiungere un middleware alias.
3. Migra un progetto di test: prendi un vecchio progetto Laravel 10, segui i passi sopra e verifica che tutto funzioni.
4. Aggiorna la documentazione interna del tuo team: spiega le differenze con un esempio concreto di middleware e routing.
5. Contatta i servizi di hosting: assicurati che il server abbia PHP 8.3+ e le estensioni richieste (BCMath, Ctype, Fileinfo, JSON, Mbstring, OpenSSL, PDO, Tokenizer, XML).

La struttura di Laravel 12 non è solo una pulizia estetica: è un cambio di paradigma che rende l’applicazione più facile da capire e mantenere. Noi lo abbiamo abbracciato da subito. Fallo anche tu.