Laravel 13.42 ajoute la lecture d’UUID et ULID et un évènement pour les migrations en échec

Laravel 13.42 est sorti le 10 novembre 2026, sans grand battage, mais avec quatre ajouts que les équipes qui maintiennent des applications en production remarqueront vite : la lecture typée d’UUID et de ULID dans les données de requête, un évènement déclenché quand une migration échoue, et un motif explicite associé à chaque tâche planifiée ignorée. Aucun changement cassant n’accompagne cette version mineure de la branche 13.x.

#Lire un UUID ou un ULID depuis la requête sans code répétitif

Jusqu’ici, extraire un UUID depuis une entrée de requête obligeait à appeler Uuid::fromString() puis à vérifier à la main l’absence de valeur. Les méthodes uuid() et ulid() ajoutées au trait InteractsWithData font les deux en une fois, et sont donc disponibles sur Request, Fluent, ValidatedInput, UriQueryString, ComponentAttributeBag et CommandInput.

$request->uuid('order_id'); // Ramsey\Uuid\UuidInterface|null
$request->ulid('order_id'); // Symfony\Component\Uid\Ulid|null

$request->safe()->uuid('order_id');

Une entrée absente ou vide renvoie null dans les deux cas ; une valeur invalide lève une exception plutôt que de laisser passer une chaîne non conforme. Pour ulid(), l’équipe a volontairement choisi new Ulid($value) plutôt que Ulid::fromString(), cette dernière acceptant d’autres formats et pouvant convertir silencieusement un UUID en un ULID différent.

#Un évènement pour réagir aux migrations qui échouent

L’évènement MigrationFailed enveloppe chaque migration dans un bloc try/catch : en cas d’échec, l’évènement se déclenche puis l’exception continue sa route normalement. L’auteur de la fonctionnalité citait le cas des instructions ALTER sous MySQL, qui ne peuvent pas être annulées : un déploiement raté peut donc laisser la base partiellement modifiée, et ce signal permet de réagir avant que quelqu’un ne le découvre à la main.

Sous MySQL, une instruction ALTER qui échoue en cours de migration laisse la base partiellement modifiée, sans retour en arrière possible : le nouvel évènement MigrationFailed donne enfin un point d’accroche pour réagir tout de suite.

Event::listen(function (MigrationFailed $event) {
    Artisan::call('down');
    Queue::pauseAll();

    Log::channel('slack')->critical("Migration [{$event->name}] failed on ".config('app.name'), [
        'exception' => $event->exception->getMessage(),
    ]);
});

#À appliquer sans urgence, mais à connaître

Rien dans cette version n’impose une montée immédiate : il s’agit d’ajouts additifs, pas de correctifs de sécurité. La commande habituelle suffit pour en profiter sur un projet existant sur la branche 13.x.

composer update laravel/framework
php artisan --version

#Le même soin que pour la maintenance des runtimes

Ce type de version mineure illustre une discipline que l’on retrouve aussi côté runtime : la publication corrective de Node.js du 11 novembre rappelle que la maintenance continue d’une pile back-end ne se limite pas aux correctifs de sécurité, elle inclut ce genre de petites commodités qui finissent par réduire la dette de code. Pour suivre ces montées de version sans douleur, les mêmes outils de ligne de commande évoqués pour Node s’appliquent à un projet Laravel. Les équipes qui suivaient déjà les apports de la version 13.40 sur la supervision des files d’attente retrouveront ici la même logique d’instrumentation, appliquée cette fois aux migrations et à l’ordonnanceur.

#Ce qu’il faut retenir

Laravel 13.42 n’a rien d’un jalon majeur, mais ses quatre ajouts — lecture typée d’UUID et de ULID, évènement de migration en échec, motif de tâche ignorée — répondent chacun à un irritant concret déjà rencontré en production. Une mise à jour sans risque, à planifier au prochain cycle de maintenance plutôt qu’en urgence.

Pour aller plus loin : le détail des pull requests est consultable sur le dépôt laravel/framework sur GitHub.