Développement

PHP 8.5 est sorti le 20 novembre. Deux fonctionnalités définissent cette version : l’opérateur pipe et l’extension URI. Elles résolvent des problèmes différents, mais partagent la même motivation : rendre les opérations courantes moins maladroites à exprimer. L’opérateur pipe Les pipelines fonctionnels en PHP ont toujours été un bazar. Enchaîner des transformations nécessitait soit d’imbriquer les appels de fonctions à l’envers, soit de les découper en variables intermédiaires : // avant — se lit de droite à gauche $result = array_sum(array_map('strlen', array_filter($strings, 'strlen'))); // ou verbeux mais lisible $filtered = array_filter($strings, 'strlen'); $lengths = array_map('strlen', $filtered); $result = array_sum($lengths); // après — se lit de gauche à droite $result = $strings |> array_filter(?, 'strlen') |> array_map('strlen', ?) |> array_sum(?); L’opérateur |> passe la valeur de gauche dans l’expression de droite. Le placeholder ? marque où elle va. Les pipelines se lisent maintenant dans l’ordre où les opérations se produisent : gauche à droite, haut en bas. ...

API Platform 4.2 est arrivé en septembre 2025. Trois changements se distinguent : un JSON streamer pour les grandes collections qui évite de bufferiser toute la réponse en mémoire, un ObjectMapper qui remplace le câblage manuel dans les flux DTO basés sur stateOptions, et l’autoconfiguration de #[ApiResource] sans enregistrement de service explicite. JSON streamer pour les grandes collections Le serializer Symfony par défaut construit la réponse complète en mémoire avant de l’écrire dans la sortie. Pour une collection de 10 000 éléments, cela signifie allouer un tableau PHP, le sérialiser en string, et garder les deux en mémoire jusqu’au flush de la réponse. À grande échelle, c’est la source des erreurs OOM qui forcent à ajouter de la pagination partout. ...

API Platform 4.1 est arrivé en février 2025 avec un lot de fonctionnalités moins axées sur de nouvelles capacités que sur la mise en production des existantes. La validation stricte des paramètres de requête gagne une propriété de première classe. OpenAPI gagne un mécanisme pour découper les grandes APIs en specs séparées. GraphQL obtient les contrôles de prévention des abus qui lui manquaient. Validation stricte des paramètres de requête La 3.3 avait introduit la validation des paramètres de requête en opt-in. La 3.4 avait déprécié le comportement permissif. La 4.1 la formalise avec une propriété native strictQueryParameterValidation sur les ressources et opérations : quand elle est à true, les paramètres de requête inconnus renvoient 400. ...

Le champ de recherche de la médiathèque renvoyait des résultats en 800 millisecondes en staging. En production, il y avait quarante fois plus de lignes. Le plan d’exécution révélait un sequential scan: aucun index sollicité, aucune façon d’y remédier avec un B-tree classique. L’équipe produit voulait aussi une recherche multi-mots: taper “interview président”, obtenir des résultats contenant les deux termes. Une requête LIKE avec des wildcards n’a pas de manière propre d’exprimer ça sans conditions indépendantes multiples, chacune nécessitant son propre scan. ...

PHP 8.4 est sorti le 21 novembre. Les property hooks sont la fonctionnalité. Tout le reste, et il y en a beaucoup, est secondaire. Les property hooks Pendant vingt ans, si on voulait du comportement à l’accès d’une propriété en PHP, il fallait écrire des getters et setters : class User { private string $_name; public function getName(): string { return $this->_name; } public function setName(string $name): void { $this->_name = strtoupper($name); } } PHP 8.4 ajoute des hooks directement sur la propriété : ...

API Platform 4.0 est sorti neuf jours après la 3.4, fin septembre 2024. Le numéro de version est honnête : il n’y a pas de nouvelle architecture, et la migration depuis la 3.4 est courte si on a résolu les dépréciations. Ce qui en fait un majeur, c’est le changement de scope — API Platform n’est plus un framework uniquement Symfony — et un défaut d’opinion qui inverse six ans de comportement PUT. ...

API Platform 3.4 est arrivé en septembre 2024 comme dernier mineur avant le saut vers la 4.0. La fonctionnalité principale est le BackedEnum comme ressource complète — pas juste un champ typé, mais un enum qui est lui-même un endpoint API. BackedEnum comme ressources API Depuis PHP 8.1, les classes BackedEnum ont un ensemble fixe de cas avec des valeurs de support string ou integer. API Platform 3.4 permet de mettre #[ApiResource] directement sur un BackedEnum : ...

API Platform 3.3 est sorti en avril 2024 avec un ensemble d’ajouts ciblés. Aucun d’eux ne remodèle l’architecture — la 3.2 avait déjà clos ce chapitre. Ce que la 3.3 apporte, c’est du contrôle sur des choses qui étaient soit codées en dur soit nécessitaient un contournement : les headers de réponse, la visibilité des liens sur les sous-ressources, et les webhooks dans la spec générée. Configuration déclarative des headers Avant la 3.3, définir des headers de réponse personnalisés nécessitait soit un processor personnalisé qui modifiait l’objet réponse, soit un event listener Symfony sur kernel.response. Les deux approches fonctionnaient mais vivaient en dehors de la définition de la ressource. ...

Symfony 7.0 est sorti le 29 novembre 2023, le même jour que 6.4. Le pattern tient : la version X.0 coupe le code déprécié et élève le plancher PHP. 7.0 exige PHP 8.2 et supprime tout ce que 6.4 avait marqué comme déprécié. La suppression la plus visible : les annotations Doctrine. @Route, @ORM\Column, @Assert — disparus. Les attributs PHP natifs sont l’approche recommandée depuis Symfony 5.2. 7.0 rend juste ça officiel. ...

Symfony 6.4 est sorti le 29 novembre 2023. C’est une LTS avec une histoire : quatre composants qui sont sortis en expérimental dans des versions précédentes sont maintenant stables. Le plus important, c’est AssetMapper. AssetMapper La gestion frontend moderne dans Symfony, ça voulait dire Webpack Encore. Encore fonctionne : il gère la transpilation, le bundling, le versioning, le hot reload. Il nécessite aussi Node.js, une étape de build séparée, et une quantité non négligeable de configuration pour ce qui est souvent un frontend assez modeste. ...