Laravel 13.36 est une mise à jour de maintenance destinée aux applications Laravel 13. Elle améliore le développement courant et l’exploitation en production sans imposer une refonte majeure.

use Illuminate\Validation\Rule;

$request->validate([
    'phone' => [
        Rule::requiredWithout('email'),
    ],
    'website' => [
        'nullable',
        Rule::url()->protocols(['https']),
    ],
    'device_id' => [
        Rule::uuid()->version(4),
    ],
]);

De nouveaux builders Rule:: fluides couvrent des règles de validation qui étaient auparavant principalement exprimées sous forme de chaînes. Ils prennent notamment en charge requiredWithout, les protocoles d’URL, les versions d’UUID, les valeurs distinctes sans tenir compte de la casse et les mots de passe confirmés. La syntaxe par chaînes reste disponible. Les builders facilitent l’autocomplétion et transmettent les paramètres de façon structurée, ce qui évite les ambiguïtés liées aux virgules dans les chaînes de règles.

DB::olap() exécute un callback avec une charge analytique sur les environnements MySQL basés sur Vitess compatibles, dont PlanetScale. Laravel rétablit la charge précédente après le callback. Sur les autres connexions, le callback s’exécute normalement. Cette méthode ne réécrit pas le SQL et ne garantit pas de meilleures performances. Les index, la conception des requêtes et la quantité de données traitées restent déterminants. Les rapports de revenus, les historiques de stock, l’analyse de l’activité client et les agrégations volumineuses font partie des usages visés.

Les workers de file d’attente de longue durée peuvent maintenant réinitialiser l’état des connexions sticky en lecture et écriture entre deux jobs. L’activation facultative passe par Worker::$flushStickyConnections = true dans AppServiceProvider. L’option reste désactivée par défaut, car certains flux dépendent d’une lecture ultérieure sur la connexion d’écriture. Les applications utilisant des réplicas ou une séparation lecture-écriture doivent valider ce changement avec soin.

Les événements diffusés uniquement vers Mercure sont désormais publiés de manière synchrone par défaut. Ceux qui ciblent aussi un autre broadcaster restent placés en file d’attente. Pour conserver une publication asynchrone vers Mercure, il faut définir MERCURE_URL="${APP_URL}/.well-known/mercure" et MERCURE_ASYNC=true. Le mode synchrone ajoute du travail à la requête en cours. Le mode asynchrone dépend du traitement par les workers.

Les mailables en file d’attente respectent maintenant #[DeleteWhenMissingModels]. Si le modèle associé a disparu, Laravel supprime le job sans lever ModelNotFoundException. L’attribut #[FailOnTimeout] est également pris en charge pour ces mailables. Un job dépassant son délai est marqué comme échoué. Le fournisseur de messagerie peut toutefois avoir accepté le message avant l’expiration, donc le risque de doublon n’est pas entièrement supprimé.

Pour les e-mails Markdown, les antislashs présents dans les valeurs fournies par les utilisateurs sont échappés avec les crochets. Une valeur spécialement construite ne peut ainsi plus modifier la cible prévue d’un lien. Cette protection concerne notamment les e-mails générés avec des profils, des commentaires, des données de commande ou des réponses d’API externes.

Le système de fichiers prend en charge les fournisseurs d’identifiants S3 nommés et les disques Cloud IAM. En mode JSON, la sortie des workers contient désormais les informations de connexion dans les messages concernés pour les arrêts, reprises et mises en pause. La récupération Redis reconstruit le client lorsqu’aucun nœud du cluster n’est accessible et libère les sockets persistants avant cette reconstruction. D’autres corrections touchent les locales des notifications, la recherche de colonnes de schéma, les requêtes, les flux d’événements, les files d’attente et plusieurs mécanismes internes.

Avant le déploiement, il faut consulter le changelog officiel et comparer Laravel 13.35 à 13.36. Les essais doivent commencer en développement ou en staging. Les tests de validation, de files d’attente, de notifications et de broadcasting méritent une attention particulière, tout comme les réglages Mercure et les connexions de base de données. Les workers et les intégrations de stockage cloud doivent aussi être vérifiés. Après la mise en production, il faut surveiller les journaux, les jobs échoués et le comportement de la base. L’adoption de toutes les nouveautés peut rester progressive.