Laravel 9 : Accrochez-vous !

Cela fait un an que l'on y travaille, et le 8 février, il a enfin été livré : Laravel 9 est là ! Dans cet article, nous allons passer en revue quelques nouvelles fonctionnalités, mais plutôt qu'une "liste de choses", je vais fournir quelques commentaires et un contexte supplémentaire sur les changements qui ont attiré mon attention.

Le gros morceau

Il n'y a pas de grands changements architecturaux ou de changements susceptibles de déclencher l'alarme de la rétrocompatibilité (ceci dit, il s'agit d'une version majeure et elle contient donc des ruptures conformes à la norme semver). Il y a cependant quelques grands changements en dehors du code. Passons-les en revue :

Cycle de libération

L'un des plus grands changements au sein de Laravel a récemment été l'annonce par Taylor Otwell du passage à un cycle de publication annuel. C'est logique, car cela donne à l'équipe principale plus de temps pour vérifier les mises à jour des dépendances au sein de l'écosystème Symfony ou des dépendances créées par la communauté. En parlant de Symfony :

Symfony Mailer

Symfony Mailer a remplacé Swift Mailer. A propos de Symfony, j'ai eu une conversation très intéressante avec les gens de SensioLabs pendant PHPUK sur le sujet des interactions entre Laravel et Symfony. Certains développeurs aiment se considérer comme des ambassadeurs de l'une ou l'autre marque, et pensent que c'est la norme "prendre parti", mais comme on peut le voir sur le site de Laravel, Symfony Mailer et Symfony, il n'y a pas de différence entre les deux. artisan cliSymfony Mailer et d'autres parties de Laravel, il est clair que les deux frameworks travaillent ensemble bien plus que ne le pensent les personnes qui essaient de semer la discorde. Il est bon de rappeler que les deux Fabien Potencier et Taylor Otwell contribuent tous deux au code de l'organisation de l'autre, et que l'écosystème PHP dans son ensemble a une pertinence et une direction modernes grâce à cela.

PHP8

Je me souviens avoir regardé Jenny Wong de Human Made donner une conférence sur la sécurité de WordPress, et comment le déploiement de Jetpack était un outil essentiel pour l'écosystème WordPress, bien que son taux d'adoption soit très faible. L'une des plus grandes vulnérabilités de PHP est la réticence des développeurs à mettre à jour leurs versions de PHP. À l'époque, plus de 50 % des utilisateurs de WordPress utilisaient des versions de PHP qui n'étaient même pas prises en charge.

C'est pourquoi il est très encourageant de voir que Laravel augmente les versions PHP requises en accord avec le cycle de vie de PHP. Cela donne accès à toute une série de nouvelles fonctionnalités d'API, mais plus important encore, forcer une version minimale de PHP8 signifie que vous obtenez le compilateur d'exécution Just-In-Time (JIT), et donc Laravel bénéficie d'une augmentation significative de la performance.

Avec une nouvelle exigence minimale, vous risquez d'être pris au dépourvu en ce qui concerne votre pile de serveurs. Si c'est une douleur sérieuse parce que vous avez des déploiements d'applications existants, je recommanderais fortement d'utiliser Laravel Shift pour migrer automatiquement vos projets.

Flysystem

L'une des meilleures caractéristiques de Laravel pour un développeur était la façon dont la façade s'enroulait autour du Flysystem de Frank De Jong. Storage s'enroulait autour du Flysystem de Frank De Jong. La possibilité de passer d'un système de fichiers local à un système de stockage AWS S3 en changeant de pilote :

Storage::disk('local')->put('something.jpg', 'Images'); Storage::disk('s3')->put('something.jpg', 'Images');

Flysystem 3.0.0 a été publié le 14 janvier et inclut des changements de version en ligne avec l'exigence minimale de Laravel pour PHP8 (pour Flysystem 8.0.2 spécifiquement) et des améliorations de l'API autour de la navigation dans les répertoires tels que FilesystemReader::directoryExists('Storage\Images')

Laravel 9 utilise désormais Flysystem 3.

Les petites choses

Il s'agit d'ajustements et d'ajouts un peu moins importants, mais qui constituent néanmoins un ensemble important de nouvelles fonctionnalités.

Groupement de contrôleurs d'itinéraires

Je dois admettre que je suis très particulier lorsqu'il s'agit d'organiser les itinéraires dans les applications web. Je pense que cela vient de l'expérience que j'ai eue en voyant des fichiers d'itinéraires massifs avec plus d'un millier d'entrées et peu de structure dans la façon dont ils sont ordonnés. La façon dont j'aime aborder le routage est d'utiliser des structures de répertoire pour les contrôleurs individuels, chargées par le fournisseur du service de routage.

Je code déjà les routes comme des groupes nommés, mais la différence ici est que la fermeture vous permettra de lier un groupe à un contrôleur spécifique. Cela ne fera pas de différence si vous adoptez l'approche des contrôleurs invocables (beaucoup plus de fichiers, mais un couplage potentiellement plus lâche), mais si vous avez quelque chose comme une API REST qui fait des opérations CRUD standard par exemple - cela semble charmant dans le code. Prenons par exemple ce contrôleur :

Class ReportController extends Controller
{
	public function index(){}
	public function store(){}
	public function delete(){}
	public function show(){}
}

Maintenant, avec le regroupement de contrôleurs, vous pouvez envelopper les méthodes du contrôleur dans le fichier de routes :

Route::controller(ReportController::class)->group(function () {
	Route::get('/reports', 'index');
	Route::post('/reports', 'store');
	Route::delete('/reports/{id}', 'delete');
	Route::get('/reports/{id}', 'show')
}

Liste d'itinéraires Sortie CLI

En parlant d'itinéraires, la sortie de routes:list a été modifiée, pour une vue beaucoup plus conviviale pour les développeurs :

Fixations à portée forcée

Il s'agit d'une petite modification intéressante qui lie les relations de modèle à la liaison de route dans une implémentation beaucoup plus claire. Auparavant, vous pouviez obtenir une liaison de portée forcée en ajoutant une clé personnalisée dans un enregistrement enfant :

Route::get('/users/{user}/reports/{report:id}', function (User $user, Report $report) {
	return $report;
})

Sans l'utilisation de cette clé personnalisée, aucune relation de modèle ne serait appliquée, ce qui signifie que tant que l'utilisateur et le rapport sont des clés valides, l'entité d'exemple $report même s'il n'y a pas de relation (par ex. Model::hasOne(User::class))

Nous disposons désormais d'une méthode qui permet d'appliquer cette logique de manière beaucoup plus explicite :

Route::get('/users/{user}/reports/{report}', function (User $user, Report $report) {
	return $report;
})->scopeBindings();

Enums

PHP8.1 est livré avec la nouvelle classe enums qui peut être traitée comme un objet avec des valeurs de retour appelées statiquement ou peut être une "énumération soutenue" qui contient une valeur. J'ai vu Derek Rethans présenter cette fonctionnalité sur scène à PHPUK 2022et je dois dire que, du point de vue de Vonage, elle pourrait s'avérer extrêmement utile. Comme nous traitons des appels vocaux et de la messagerie, beaucoup de ces fonctionnalités mises en œuvre dans le PHP SDK ont des propriétés statiques pour définir et récupérer l'état (par exemple, le statut de ce SMS est "0"). Les Enums ont le potentiel d'avoir un type associé, plutôt qu'une longue liste de propriétés statiques.

Avec l'introduction des Enums, quelques fonctionnalités de Laravel 9 ont été écrites pour en tirer profit.

Attribut cast Enums

J'ai travaillé sur un projet où cela aurait vraiment, vraiment évité beaucoup de maux de tête. Tout dans une base de données MySQL assez importante s'étendait à partir d'une classe de base/table de base "Event", les entités étendues étant restreintes par des enums MySQL. Cela semble correct, n'est-ce pas ? Lorsque nous avons étendu la plate-forme, il a fallu ajouter une nouvelle énumération, ce qui a entraîné une réindexation d'une table contenant plusieurs centaines de millions d'enregistrements. Cela tombait à l'eau à chaque fois.

Réfléchissez à la manière dont vous écririez une migration pour une colonne d'un tableau de type "enum" :

$table->enum('eventType', ['SpotifyEvent', 'VideoEvent', 'AppleEvent'])

OK, donc chaque fois que vous ajoutez un nouvel enum, une nouvelle migration doit être effectuée, et vous devez mettre à jour le modèle.

Dans Laravel 9, vous pouvez spécifier une classe enum à la place, en gardant la logique dans votre code backend plutôt que dans votre base de données. Bien que ce soit un inconvénient du point de vue de la base de données avec un stockage inefficace, on peut dire que cela rend le code plus lisible. Ainsi, votre migration serait une colonne varchar à la place :

$table->string('eventType')->default('SpotifyEvent');

Et votre logique se situerait dans une classe enum soutenue qui est référencée à l'intérieur du modèle $casts dans le tableau du modèle :

enum EventType: string {
	case SpotifyEvent = 'spotify';
	case VideoEvent = 'video';
	case AppleEvent = 'apple';
}

class EventEntry extends Model
{
	protected $casts = [
		'eventType' => EventType::class
	];
}

C'est ainsi que nous avons lié notre casting à la base de données et à la base de données : vous pouvez l'essayer avec tinker :

php artisan tinker

\App\Model\EventEntry::first()->eventType->value;

Et votre chaîne de caractères vous sera retournée. eventType retournera en fait un objet enum, c'est pourquoi nous devons ajouter l'attribut value afin d'obtenir la propriété adossée.

Liaison des itinéraires avec les Enums

Vous pouvez également utiliser des classes d'énumération dans le cadre de la liaison d'itinéraires. Supposons que vous souhaitiez restreindre l'itinéraire suivant :

Route::get('events/eventType');

Vous pouvez maintenant lier la classe enum, comme suit :

Route::get('/events/{eventType}', function (EventType $eventType) {
	return $eventType->value;
});

Couverture des tests

Revenir à Xdebug pour l'utiliser dans ma chaîne d'outils de développement quotidienne a été une sorte de révélation après des années d'utilisation de die() et de dd() débogage. Lorsque j'ai commencé à travailler sur notre SDK PHP, j'ai vu que notre CI utilisait CodeCov pour s'assurer que les Pull Requests ne peuvent pas être fusionnées sans une couverture suffisante dans la suite de tests. La couverture est offerte par Xdebug, vous devez donc activer la couverture dans votre fichier .ini en premier lieu :

xdebug.mode=develop,debug,coverage

Maintenant, si vous exécutez artisan test --coveragevous obtiendrez un rapport sur la couverture de votre application :

Pas mal, hein ?

Et ensuite ?

Cette version marque une nouvelle étape dans le parcours de Laravel, mais ce qui est vraiment étonnant, c'est l'écosystème étendu construit autour de lui - Vapor, Breeze, Octane, Sail, Horizon... la liste est longue. Ce que je trouve passionnant dans la liste sans cesse croissante des projets Laravel, c'est son inclusion dans la Fondation PHPcréée dans le sillage du départ à la retraite de le retrait de Nikita Popov du développement principal de PHP. Aux côtés de Symfony, il est clair que la phrase immortelle "PHP est mort"ne pourrait pas être plus éloignée de la vérité.