Laravel 11 naujovės ir migracijos vadovas

Kas naujo Laravel 11 versijoje?

Laravel 11 atėjo su gana rimtais pakeitimais, kurie iš pirmo žvilgsnio gali pasirodyti net šiek tiek radikalūs. Bet neskubėkite išsigąsti – dauguma naujovių yra orientuotos į tai, kad jūsų kodas būtų švaresnis, paprastesnis ir lengviau prižiūrimas. Pirmiausia pastebėsite, kad projekto struktūra tapo minimalistinė. Išnyko daugelis tų failų, kuriuos tikriausiai niekada nelietėte, bet jie vis tiek gulėjo jūsų `app` kataloge.

Vienas didžiausių pasikeitimų – tai nauja aplikacijos struktūra. Jeigu anksčiau turėjote `app/Http/Kernel.php`, kuriame registravote middleware ir kitas paslaugas, dabar to neberasite. Visa tai persikėlė į `bootstrap/app.php` failą, kuris tapo centrine konfigūracijos vieta. Tai gali atrodyti keista, bet praktikoje dirba puikiai – viskas vienoje vietoje, mažiau failų, kuriuose reikia kapstyti.

Dar viena įdomi detalė – `RouteServiceProvider` išnyko. Taip, tiesiog dingo. Dabar maršrutai konfigūruojami tiesiogiai per `bootstrap/app.php`, ir tai iš tikrųjų supaprastina procesą. Nebereikia galvoti, kur kas yra apibrėžta – tiesiog atidarai vieną failą ir matai visą konfigūraciją.

Middleware tvarkos pokyčiai

Middleware sistema buvo viena iš sričių, kuri sulaukė nemažai dėmesio Laravel 11. Anksčiau turėjote `$middleware`, `$middlewareGroups` ir `$routeMiddleware` masyvas `Kernel.php` faile. Dabar viskas veikia per fluent API stilių `bootstrap/app.php` faile.

Praktiškai tai atrodo taip:

„`php
->withMiddleware(function (Middleware $middleware) {
$middleware->web(append: [
\App\Http\Middleware\HandleInertiaRequests::class,
]);
})
„`

Iš pradžių gali pasirodyti neįprasta, bet kai įprantate, tai tampa daug aiškiau. Galite lengvai pridėti, pašalinti ar pakeisti middleware tvarką naudodami `append`, `prepend` ar `remove` metodus. Be to, dabar lengviau valdyti middleware prioritetus ir grupavimą.

Dar vienas svarbus dalykas – kai kurie middleware dabar yra įjungti pagal nutylėjimą ir jų nebereikia rankiniu būdu registruoti. Pavyzdžiui, `TrimStrings` ir `ConvertEmptyStringsToNull` veikia automatiškai, nebent juos išjungiate.

Konfigūracijos failų optimizacija

Laravel 11 komanda nusprendė, kad dauguma projektų naudoja standartines konfigūracijas ir nėra prasmės turėti dešimtis failų `config` kataloge, jei 90% jų niekada neliečiate. Todėl dabar naujame projekte rasite tik kelis pagrindinius konfigūracijos failus: `app.php`, `database.php` ir dar porą.

Bet ką daryti, jei jums reikia pakeisti kažkokį specifinį nustatymą, kurio failas nebeegzistuoja? Čia ir slypi gudrybė – galite bet kada publikuoti reikiamą konfigūracijos failą naudodami Artisan komandą:

„`bash
php artisan config:publish queue
„`

Tai publikuos `queue.php` failą į jūsų `config` katalogą, ir galėsite jį redaguoti kaip įprastai. Jei norite publikuoti visus konfigūracijos failus vienu metu, naudokite `–all` flag’ą. Tai labai patogu, ypač jei migravote iš senosios versijos ir norite turėti pilną kontrolę.

Aplinkos kintamieji taip pat tapo šiek tiek paprastesni. Dabar galite naudoti `.env` faile naujus formatus ir funkcijas, kurios anksčiau neveikė. Pavyzdžiui, dabar galite naudoti kabutes su tarpais be jokių problemų.

Maršrutų sistema ir jos pakeitimai

Maršrutų valdymas Laravel 11 tapo gerokai lankstesnis. Kaip minėjau anksčiau, `RouteServiceProvider` išnyko, bet tai nereiškia, kad praradote funkcionalumą. Priešingai – dabar turite daugiau kontrolės.

Pagal nutylėjimą naujas Laravel 11 projektas ateina tik su `web.php` maršrutų failu. Jei jums reikia API maršrutų, galite juos lengvai įjungti:

„`bash
php artisan install:api
„`

Ši komanda sukurs `routes/api.php` failą ir sukonfigūruos viską, kas reikalinga API veikimui, įskaitant Sanctum autentifikaciją. Analogiškai veikia ir broadcasting funkcionalumas – įdiegiate tik tada, kai reikia.

Vienas iš dalykų, kurį tikrai reikia žinoti – maršrutų kešavimas dabar veikia šiek tiek kitaip. Jei turėjote custom logikos `RouteServiceProvider`, ją reikės perkelti į `bootstrap/app.php` arba sukurti atskirą service provider’į. Bet dažniausiai to nereikia, nes standartinė konfigūracija tinka daugumai projektų.

Duomenų bazės ir modelių naujovės

Eloquent modeliai gavo keletą malonių patobulinimų. Vienas iš jų – `casts` metodas, kuris dabar gali būti apibrėžtas kaip metodas, o ne tik kaip property. Tai leidžia turėti dinamiškesnį casting’ą:

„`php
protected function casts(): array
{
return [
’email_verified_at’ => ‘datetime’,
‘password’ => ‘hashed’,
‘options’ => AsCollection::class,
];
}
„`

Migracijos taip pat sulaukė dėmesio. Dabar galite naudoti naują `Schema::dropColumns()` metodą, kuris leidžia ištrinti kelis stulpelius vienu metu be papildomo sintaksės. Smulkmena, bet malonu.

Dar vienas naujas dalykas – modelių default values dabar gali būti apibrėžti per `attributes` metodą, kuris veikia panašiai kaip `casts`. Tai suteikia daugiau lankstumo ir leidžia naudoti dinaminius default’us.

Jei naudojate SQLite, džiaugsitės žinodami, kad Laravel 11 turi geresnę SQLite palaikymą, įskaitant foreign key constraints ir kitus dalykus, kurie anksčiau veikė tik su MySQL ar PostgreSQL.

Migracijos procesas iš senesnių versijų

Dabar prie smagiausios dalies – kaip iš tikrųjų perkelti esamą projektą į Laravel 11? Pirmas dalykas, kurį turite žinoti – tai nėra paprastas `composer update`. Yra nemažai dalykų, kuriuos reikės pakeisti rankiniu būdu.

Pradėkite nuo `composer.json` failo atnaujinimo. Pakeiskite Laravel versiją į `^11.0` ir atnaujinkite visus kitus paketus, kurie turi Laravel 11 palaikymą. Kai kurie paketai gali dar neturėti palaikymo, todėl būtinai patikrinkite jų dokumentaciją.

Toliau – `bootstrap/app.php` failas. Jums reikės jį visiškai perrašyti pagal naują struktūrą. Štai bazinė struktūra:

„`php
withRouting(
web: __DIR__.’/../routes/web.php’,
commands: __DIR__.’/../routes/console.php’,
health: ‘/up’,
)
->withMiddleware(function (Middleware $middleware) {
//
})
->withExceptions(function (Exceptions $exceptions) {
//
})->create();
„`

Jei turėjote custom middleware ar kitos logikos `Kernel.php`, ją reikės perkelti į atitinkamas `withMiddleware` ar `withExceptions` sekcijas. Tai gali užtrukti, bet procesas gana tiesioginis.

`RouteServiceProvider` turinį reikės perkelti. Jei turėjote custom maršrutų konfigūraciją, ją galite apibrėžti `withRouting` metode. Pavyzdžiui, jei turėjote custom prefix’us ar namespace’us, juos galite nurodyti ten.

Potencialios problemos ir jų sprendimai

Migracija niekada nebūna visiškai sklandi, todėl pasidalinsiu keletu dažniausiai pasitaikančių problemų ir jų sprendimų.

Pirmiausia – trečiųjų šalių paketai. Kai kurie paketai, ypač tie, kurie modifikuoja Laravel branduolį ar naudoja vidines API, gali neveikti. Prieš pradėdami migraciją, patikrinkite visų savo naudojamų paketų GitHub’o issues ar dokumentaciją dėl Laravel 11 palaikymo.

Jei naudojate Inertia.js ar Livewire, turėsite atnaujinti ir juos. Inertia 1.0 puikiai veikia su Laravel 11, bet senesnės versijos gali kelti problemų. Livewire v3 yra rekomenduojama versija Laravel 11 projektams.

Testai – tai dar viena sritis, kur galite susidurti su problemomis. Jei jūsų testai tiesiogiai priklausė nuo `Kernel.php` ar `RouteServiceProvider`, juos reikės atnaujinti. Dažniausiai tai reiškia, kad reikia pakeisti, kaip mock’inate ar override’inate middleware.

Dar viena dažna problema – custom Artisan komandos. Jei turėjote komandų, kurios registruojamos `RouteServiceProvider` ar `Kernel.php`, jas reikės perkelti į `routes/console.php` arba naudoti auto-discovery mechanizmą, kuris dabar veikia geriau.

Session ir cache driver’iai kartais gali kelti problemų po migracijos. Jei naudojate Redis ar Memcached, įsitikinkite, kad jūsų konfigūracija yra teisinga naujoje struktūroje. Gali tekti išvalyti cache ir session duomenis po migracijos.

Ar verta migravoti dabar ir kaip tai padaryti protingai

Atsakymas į klausimą „ar verta migravoti” priklauso nuo jūsų projekto. Jei kuriate naują projektą – tikrai naudokite Laravel 11. Jei turite esamą projektą, kuris veikia gerai su Laravel 10, skubėti nereikia. Laravel 10 gaus palaikymą dar ilgai.

Bet jei nusprendėte migravoti, darykite tai protingai. Pirma, sukurkite atskirą git branch’ą. Antra, turėkite gerą testų coverage – tai padės greitai identifikuoti, kas sulūžo. Trečia, migravokite development aplinkoje ir kruopščiai testuokite prieš keisdami production.

Rekomenduočiau migravoti etapais. Pirmiausia atnaujinkite composer dependencies ir patikrinkite, ar viskas kompiliuojasi. Tada perkelkite middleware konfigūraciją. Po to – maršrutus. Ir galiausiai – bet kokią custom logiką. Kiekviename etape testuokite, ar viskas veikia.

Naudokite Laravel Shift, jei norite automatizuoti dalį proceso. Tai mokama paslauga, bet ji gali sutaupyti daug laiko, ypač dideliems projektams. Bet vis tiek turėsite rankiniu būdu peržiūrėti ir patikrinti pakeitimus.

Ir paskutinis patarimas – skaitykite upgrade guide’ą Laravel dokumentacijoje. Ten rasite visą oficialią informaciją apie tai, kas pasikeitė ir kaip migravoti. Šis straipsnis suteikia praktinius patarimus, bet oficiali dokumentacija visada turėtų būti jūsų pagrindinis šaltinis.

Laravel 11 yra puikus atnaujinimas, kuris daro framework’ą švaresniu ir paprastesniu. Taip, migracijos procesas nėra trivialus, bet rezultatas to vertas. Jūsų kodas bus švaresnis, lengviau prižiūrimas, ir turėsite prieigą prie naujausių funkcijų. Tereikia skirti laiko ir daryti viską metodiškai – tada viskas bus gerai.

Daugiau

Python FastAPI ir Django: našumo testas