--- title: "Perché è sempre meglio aggiornare Laravel" date: 2025-02-23 lang: it tags: [Laravel, PHP] description: "È molto importante tenere aggiornate le proprie applicazioni affinché usino l'ultima versione di Laravel" --- Ieri (24 febbraio 2025) è uscito [Laravel 12](https://laravel.com/docs/12.x). Questo mi dà lo spunto per parlare di quanto sia importante (e perché lo sia) **aggiornare sempre** le proprie applicazioni affinché usino l'ultima versione del framework. ## Che palle, devo proprio aggiornare? ![Stanco o annoiato?](/blog/perche-e-sempre-meglio-aggiornare-laravel/tired-or-bored.jpg "tired-or-bored") Risposta breve: **sì**, devi. Per vari motivi. Utilizzare la versione più aggiornata del framework ti consente di: - usufruire delle **ultime funzionalità** rilasciate su Laravel: nuovi metodi _Eloquent_ o sulle _Collection_, nuovi helper o _facade_, classi con una sintassi fluente e più gradevole, wrapper di funzioni PHP relative a versioni recenti, nuovi asserzioni nei metodi di test, eccetera - beneficiare delle più recenti correzioni relative alla **sicurezza** - utilizzare **package di prima parte** (es. Reverb, Pulse, Pennant, ecc.) che non sono disponibili per versioni meno recenti - utilizzare **tecnologie**, protocolli, prodotti o API supportati solo dalle più recenti versioni del framework - poter utilizzare le versioni più aggiornate dei **package di terze parti** necessari alla tua applicazione, usufruendo così delle aggiunte rilasciate - godere di una **DX (Developer eXperience)** di alto livello, grazie anche agli strumenti pensati per le versioni più recenti del framework (es. Pest, Pint, Larastan, Rector, ecc.) o alle funzionalità messe a disposizione dalle ultime _release_ di PHP (sintassi, nuovi operatori, attributi, correzioni varie) In poche parole, tutto ciò ti consente di **non restare indietro** ed evitare di andare incontro a obsolescenza certa. ## Non voglio aggiornare ![no](/blog/perche-e-sempre-meglio-aggiornare-laravel/no.png "no") Puoi anche decidere di non farlo, ma credimi: questa decisione, prima o poi, **ti si ritorcerà contro**. Parlo per esperienza diretta! 😁 Supponiamo, ad esempio, che mantieni un'applicazione importante, con una _codebase_ piuttosto grossa, scritta con **Laravel 7**. Per vari motivi, non l'hai mai aggiornata. Il codice ha sempre funzionato senza problemi; il cliente ogni tanto ha chiesto qualche modifica e tu l'hai realizzata; hai sempre sistemato i bug che si sono presentati nel tempo. Nel frattempo, **siccome non vivi nelle caverne** e ami **tenerti aggiornato**, hai sempre tenuto d'occhio le **novità** nel mondo Laravel: nuove funzionalità, strumenti da riga di comando, analizzatori statici, framework per i test, linter, package fantastici, eccetera. Peccato che tutto ciò tu non lo possa usare perché è disponibile, diciamo, dalla versione 10 di Laravel in poi. Inoltre, la tua applicazione gira ancora con PHP 7.x, quindi fino ad ora hai dovuto anche rinunciare ad usare la sintassi e tutte le comodità della versione 8.x. Per non parlare del fatto che il supporto a PHP 7.x è cessato da un pezzo, per cui vai incontro a possibili problemi di sicurezza e con il tempo diventa complicato configurare un VPS con _stack_ applicativi obsoleti (e magari non sei proprio a tuo agio con Docker). All'improvviso hai bisogno di introdurre notifiche in tempo reale via websocket. Perfetto, c'è **Laravel Reverb**! Peccato che tu non lo possa usare perché richiede almeno la versione 10! A un certo punto valuti anche di riscrivere l'applicazione da zero, partendo da `laravel new` e riciclando parti di codice prese dalla attuale applicazione. La scarti quasi immediatamente: troppo lungo e complicato. Non hai scampo: **sei costretto ad aggiornare**. Buona fortuna! 😁 Passare dalla versione N alla N+1 di Laravel può essere relativamente semplice; ma passare da N a N+5 può essere **un vero inferno**. E ti maledirai per aver aspettato così tanto tempo. Avrai a che fare con - package non più supportati - vari _breaking change_ del framework - svariati _breaking change_ in più di un package che utilizzi nell'applicazione - codice deprecato che va riscritto per una versione più attuale di PHP e/o di Laravel - molto altro ancora a cui ora non voglio nemmeno pensare ma che si tradurrà sicuramente in mal di testa, ora spese a cercare in rete, attimi di disperazione ## Quando mi conviene aggiornare? Non immediatamente, ma **non fare passare troppo tempo**. Subito potrebbe essere **prematuro**: potresti andare incontro a problemi, bug o casi particolari per cui non trovi (ancora) soluzioni negli _issue_ di GitHub, su StackOverflow, su Reddit né tantomeno su ChatGPT e simili. Anche se volessi avventurarti, potresti scontrarti con **dipendenze Composer non ancora pronte**: package che non supportano ancora l'ultima versione di Laravel. Quando esce una nuova versione di Laravel, molti addetti ai lavori sono in fibrillazione già da tempo, principalmente per aggiornare i propri **package** affinché siano installabili anche sulla versione più recente del framework. Il panorama è variegato: - chi si porta avanti con largo anticipo, rilasciando una nuova versione già parecchi giorni o, a volte, addirittura settimane prima: fra questi, ad esempio, la nostra web agency spaziale belga preferita 😁 - all'opposto, chi aggiorna il proprio package con settimane o addirittura mesi di ritardo, costringendo chi lo utilizza a non poter aggiornare la propria applicazione o a dover trovare un'alternativa (fork, altro package, ecc.) - chi aiuta altri maintainer aprendo un Pull Request che realizza l'aggiornamento: è un buon metodo per essere utili e riconoscenti alla comunità _open-source_, per imparare qualcosa di nuovo e, non ultimo, per velocizzare i tempi di uscita di quel package - chi decide di non aggiornare il proprio package Si tratta di variabili di cui bisogna necessariamente tenere conto. ## Lo farò un giorno. Ora ho problemi più urgenti ![futuramente](/blog/perche-e-sempre-meglio-aggiornare-laravel/futuramente.jpg "futuramente") Ok, ma **non fare passare troppo tempo**. **Pianifica** questa attività, metti un promemoria e trova il tempo per portarla a termine. Non te ne pentirai. Se lasci passare troppo tempo, finirai per dimenticartene e potresti ritrovarti anni dopo nell'inferno descritto più sopra. ## Il cliente non mi paga, quindi non aggiorno In breve: **dovresti aggiornare comunque**. Sulla carta, il ragionamento non fa una piega: _niente soldi, niente cammello_. Peccato che non vendi frutta o abiti ma software e servizi (che vanno necessariamente mantenuti e aggiornati). ![Niente soldi, niente cammello](/blog/perche-e-sempre-meglio-aggiornare-laravel/camel.jpg "camel") Magari hai anche provato a spiegare il problema al tuo cliente, ma lui ha risposto > "l'applicazione sta funzionando. Non possiamo permetterci di spendere altri soldi; al limite, preferisco tenerli da parte per sviluppi futuri" C'è un grosso errore di fondo: **non spetta al cliente prendere questo tipo di decisioni**. Non avresti nemmeno dovuto porgli questa domanda: il più delle volte, il cliente non ha le **competenze tecniche** per valutare se e quando sia meglio aggiornare un framework o che versione di PHP sia più opportuno usare. E se le ha (ad esempio, ti interfacci con il dipartimento _IT_), dà per scontato che tu segua le _best practice_ relative a manutenzione, aggiornamento, sicurezza. Si aspetta, quindi, che **prenda tu questo genere di decisioni**, eventualmente discutendo con lui eventuali problematiche legate a costi o periodi in cui l'applicazione non può essere utilizzata dagli utenti causa aggiornamento/manutenzione. ## Quindi ci devo rimettere io? Risposta breve: **non ci rimetti tu. Anzi**. Il tuo primo pensiero potrebbe essere questo: > "ora dovrò perdere ore per aggiornare versione del framework, combattendo contro conflitti di versione tra package e test che non ne vogliono sapere di passare. Nessuno mi paga queste ore. Chi me lo fa fare?" Partiamo dalla questione economica: probabilmente stai sbagliando qualcosa nella parte contrattuale/economica con il cliente. Siamo d'accordo: non puoi emettere una fattura dove indichi _aggiornamento Laravel alla versione 12_ o _aggiornamento di spatie/laravel-permission_. Tuttavia, si presume che tu abbia previsto un **canone** mensile o annuo relativo a supporto, aggiornamento e manutenzione applicativa: gli aggiornamenti di Laravel, delle sue dipendenze e simili rientrano in questi compensi. Se non sei proprio alle prime armi e non hai previsto un canone simile, la vedo così: _o hai sbagliato cliente o hai sbagliato lavoro_. So che suona un po' duro e antipatico, ma è la realtà. Non solo non ci rimetterai, ma ne guadagnerai anche, per i motivi spiegati sopra: avrai una **DX** più piacevole, potrai realizzare nuove funzionalità in modo più sicuro e "moderno", manterrai aggiornata la tua applicazione nel lungo termine. ## Ok, mi hai convinto: come faccio? ![Aggiornamento](/blog/perche-e-sempre-meglio-aggiornare-laravel/update.jpg "update") **Test**, test, e ancora test: per cominciare, la tua applicazione deve avere una **suite di test** la più completa possibile (no, non serve una _coverage_ né del 100% né del 75% perché sono numeri che di per sé non vogliono dire molto). Questo è il metodo più rapido per vedere se qualcosa "si rompe" o se continua a funzionare tutto dopo l'aggiornamento. Attenzione: se tutti i test passano, non hai la garanzia assoluta che sia tutto funzionante al 100%; allo stesso tempo, se dopo l'aggiornamento un test non passa più, hai l'evidenza della presenza di un _bug_. Come disse **Edsger Dijkstra**: > "Il test di un programma può essere usato per mostrare la presenza di bug, ma mai per mostrare la loro assenza" A meno che la tua applicazione non sia una semplice _landing page_ (volendo si potrebbe discutere sull'utilità di vari tipi di test anche per un caso così semplice) e testare a mano le funzionalità ti richieda due minuti, pensare di fare la stessa cosa per un'applicazione più grande o complessa è decisamente fuori discussione. Richiederebbe troppo tempo, sarebbe un procedimento inesatto e incompleto e, sicuramente, non considereresti tutti gli scenari, i casi d'uso e gli _input_ dell'utente. Ovviamente, **segui la guida**. Ogni nuova versione di Laravel riporta una guida all'aggiornamento. Ad esempio, se passi dalla versione 11 alla 12, devi eseguire [questi passaggi](https://laravel.com/docs/12.x/upgrade). Per fortuna, in questo caso si tratta di un aggiornamento con zero _breaking change_, quindi dovrebbe essere piuttosto semplice. Altro passaggio obbligatorio: segui la **guida** all'aggiornamento dei **package** presenti fra le dipendenze. Utilizza **strumenti di sviluppo** che ti aiutino a rendere più "moderno" e aggiornato il tuo codice: ad esempio, **Larastan** e **Rector**. Oltra all'ambiente locale - che sia basato su Herd, Laragon, Docker o altro non importa - effettua un rilascio su un **ambiente di staging** o pre-produzione, dove più utenti (specialmente quelli finali) possano testare l'applicazione, possibilmente per diversi giorni. Puoi anche avere una suite con migliaia di test e decine di migliaia di asserzioni, ma i **test utente** sono comunque necessari. Valuta eventualmente se farti aiutare da una **soluzione automatizzata** quale [Laravel Shift](https://laravelshift.com/). **Buon aggiornamento!**