Laravel 12 – Wat is er nieuw?

Laravel 12 verscheen op 24 februari 2025. Het is een bewust rustige release: het framework zelf verandert nauwelijks, de meeste applicaties upgraden zonder een regel code aan te passen, en de echte vernieuwing zit in de starter kits. In dit artikel zetten we op een rij wat er nieuw is, welke breaking changes je wél kunt raken, en hoe je de upgrade aanpakt.

Een onderhoudsrelease, en dat is goed nieuws

Waar eerdere major versies soms ingrijpende veranderingen brachten (denk aan de afgeslankte applicatiestructuur van Laravel 11), richt Laravel 12 zich op het bijwerken van upstream dependencies. Het team noemde het zelf een maintenance release. Voor teams betekent dat: de upgrade kost weinig tijd, en je krijgt er vooral een langere supportperiode voor terug.

De belangrijkste randvoorwaarden:

• PHP 8.2 of hoger is vereist; inmiddels wordt ook PHP 8.5 ondersteund. Draai je nog op PHP 8.1, dan moet je eerst PHP upgraden.
• Carbon 3 is verplicht; ondersteuning voor Carbon 2 is vervallen.
• Support: bugfixes liepen tot 13 augustus 2026, securityfixes lopen nog tot 24 februari 2027.

De nieuwe starter kits

De grootste zichtbare verandering. Breeze en Jetstream, de starter kits van de afgelopen jaren, krijgen geen nieuwe features meer. In hun plaats kwamen nieuwe kits, die je kiest bij laravel new:

• React: Inertia 2, React 19, TypeScript, Tailwind en componenten van shadcn/ui.
• Vue: Inertia 2, Vue 3 met de Composition API, TypeScript, Tailwind en shadcn-vue.
• Livewire: Livewire met de componentbibliotheek Flux UI.
• Svelte: later toegevoegd, met Inertia 2, Svelte 5 en shadcn-svelte.

Alle kits bevatten registratie, inloggen, wachtwoordherstel, e-mailverificatie en een instellingenpagina. Net als bij Breeze komt de code volledig in je eigen applicatie terecht; wat je installeert, is van jou. Nieuw is vooral de moderne frontend-stack: TypeScript, Inertia 2 en een kant-en-klare componentbibliotheek.

Elke kit heeft daarnaast een variant met WorkOS AuthKit. Daarmee krijg je social login, passkeys, magic links en SSO zonder dat je dat zelf bouwt. AuthKit is een externe dienst met een ruime gratis laag; controleer de actuele voorwaarden van WorkOS voordat je er een productieapplicatie op bouwt. Wil je authenticatie volledig in eigen beheer houden, kies dan de standaardvariant.

Breaking changes die je kunt raken

De officiële upgrade-gids schat de impact voor de meeste applicaties laag in. Toch zijn er een paar wijzigingen die in de praktijk opduiken:

UUID's worden versie 7

Modellen met de trait HasUuids genereren voortaan UUIDv7 in plaats van de geordende UUIDv4-variant. UUIDv7 is tijdgebaseerd en sorteert goed in database-indexen. Heb je code die afhankelijk is van het oude formaat, gebruik dan HasVersion4Uuids:

use Illuminate\Database\Eloquent\Concerns\HasVersion4Uuids as HasUuids;

class Bestelling extends Model
{
    use HasUuids;
}

SVG telt niet meer als afbeelding

De validatieregel image accepteert standaard geen SVG-bestanden meer. SVG kan JavaScript bevatten, en een geüploade SVG die je ongefilterd terugserveert is een XSS-risico. Wil je SVG toch toestaan, dan moet je dat expliciet zeggen:

$request->validate([
    'logo' => ['required', 'image:allow_svg'],
]);

Doe dat alleen als je de SVG daarna saneert of vanaf een apart domein serveert.

De local-disk staat in een andere map

Als je in config/filesystems.php geen eigen local-disk hebt gedefinieerd, schrijft die voortaan naar storage/app/private in plaats van storage/app. Bestaande bestanden verhuizen niet vanzelf mee. Definieer de disk expliciet als je het oude pad wilt houden.

Carbon 3

Carbon 3 gedraagt zich op een paar punten anders dan Carbon 2. Het bekendste verschil: diffInDays() en verwante methoden geven nu een float terug en kunnen negatief zijn, afhankelijk van de volgorde van de datums. Code die verschillen in dagen vergelijkt of in een int-property stopt, moet je nalopen.

// Carbon 2: 3
// Carbon 3: -3.0 als $eind voor $start ligt
$start->diffInDays($eind);

// Expliciet en voorspelbaar:
(int) abs($start->diffInDays($eind));

De upgrade in vier stappen

1. Controleer je PHP-versie. Minimaal 8.2. Draait productie nog op een oudere versie, regel dat eerst; dat is meestal het grootste deel van het werk. Lees hoe een gefaseerde PHP-migratie werkt.
2. Werk composer.json bij. Zet laravel/framework op ^12.0, en ook first-party packages die een nieuwe major hebben. Controleer of je third-party packages Laravel 12 ondersteunen; dat is in de praktijk vaker de blokkade dan het framework zelf.
3. Loop de upgrade-gids na op de punten hierboven: UUID's, SVG-validatie, de local-disk en Carbon 3.
4. Draai je testsuite en een rondje statische analyse. Zonder tests is elke upgrade gokken; zie ook ons artikel over SOLID-principes in PHP voor code die beter testbaar is.

Wie geautomatiseerd wil upgraden, kan Laravel Shift gebruiken: een betaalde dienst die een pull request maakt met de benodigde aanpassingen. Voor deze release is handmatig upgraden meestal sneller.

Moet je de starter kits gebruiken in een bestaand project?

Nee. De nieuwe kits zijn bedoeld voor nieuwe applicaties. Een bestaande applicatie op Breeze of Jetstream blijft gewoon werken; die code staat al in je project. Je mist alleen toekomstige verbeteringen aan de kits zelf. Een migratie naar de nieuwe kits loont alleen als je toch je frontend herschrijft.

En daarna?

Laravel volgt een jaarlijkse releasecyclus. Inmiddels is Laravel 13 uitgebracht, met PHP 8.3 als minimumversie. Omdat Laravel 12 sinds augustus 2026 alleen nog securityfixes krijgt, en ook die in februari 2027 stoppen, is het verstandig de stap naar 13 in te plannen. Teams die elk jaar meegaan, houden elke upgrade klein; teams die een paar versies overslaan, krijgen uiteindelijk een migratieproject.

Benieuwd hoe vaak Laravel gevraagd wordt in Nederlandse vacatures, vergeleken met Symfony? Dat lees je in de State of PHP in Nederland 2026.