Symfony 7 et Sylius 2.0 : Ce qui Change pour les Developpeurs

Sylius 2.0 supporte a la fois Symfony 6.4 LTS et Symfony 7.1+. Pour les developpeurs qui faisaient tourner Sylius 1.x sur Symfony 5 ou 6, cela represente une modernisation significative du stack. Analysons ce que Symfony 7 apporte et ce que cela signifie concretement pour vos projets Sylius.

Symfony 7 : ce qui change

Symfony 7 est sorti en novembre 2023. C'est la version "propre" qui supprime tout ce qui a ete deprecie dans le cycle 6.x. Si vous avez ignore les notices de deprecation, Symfony 7 est la ou elles deviennent des erreurs fatales.

PHP 8.2 minimum

Symfony 7 requiert PHP 8.2+, et Sylius 2.0 s'aligne sur ce minimum. Si vos serveurs de production tournent encore en PHP 8.1, vous devrez d'abord mettre a jour votre runtime.

C'est generalement une bonne chose : PHP 8.2 apporte les classes readonly et des ameliorations de performance significatives, et si vous passez a PHP 8.3 vous obtenez aussi les constantes de classe typees et la fonction json_validate().

Toutes les deprecations supprimees

Chaque methode, classe et option de configuration marquee @deprecated dans Symfony 6.x est supprimee dans Symfony 7. Les suppressions les plus impactantes pour les projets Sylius incluent :

• Securite : l'ancienne configuration security.encoders est supprimee. Vous devez utiliser security.password_hashers.
• Mailer : l'integration SwiftMailer a ete supprimee (la librairie elle-meme a ete abandonnee par ses mainteneurs en 2021). symfony/mailer est le remplacement standard dans Sylius 2.0.
• Routing : les annotations en commentaires (@Route, reposant sur SensioFrameworkExtraBundle) ne sont plus supportees. Utilisez les attributs PHP 8 #[Route], supportes par Symfony depuis la version 5.2.
• DI : certains raccourcis de configuration du container ont ete supprimes.

Approche attributs-first

Symfony 7 mise a fond sur les attributs PHP partout : routing, security voters, event subscribers, configuration DI. Si votre projet Sylius utilise encore du YAML ou des annotations pour les controllers et services custom, c'est le moment de moderniser.

Ce que cela signifie pour Sylius 2.0

Les Twig Hooks deviennent l'approche de personnalisation recommandee

Ce changement est specifique a Sylius, fourni par le package sylius/twig-hooks (qui supporte Symfony 6.4 et 7.x). L'ancien pattern de surcharge de templates Twig entiers en placant des fichiers dans templates/bundles/ fonctionne toujours mais est decourage en faveur des Twig Hooks : un systeme ou vous enregistrez de petits fragments de templates qui se branchent sur des points d'extension specifiques.

Les Twig Hooks remplacent principalement les anciens systemes Sylius Template Events et Sonata Block Events. L'avantage : vos personnalisations sont plus granulaires et survivent mieux aux mises a jour du core Sylius. Le cout : les overrides existants doivent etre reecrits si vous voulez suivre la nouvelle approche.

Symfony Workflow remplace winzou

Sylius 1.x reposait sur winzou/state-machine-bundle pour les workflows de commande, de paiement et d'expedition. Sylius 2.0 utilise le composant natif Workflow de Symfony.

Differences cles pour les developpeurs :

• La configuration passe de winzou_state_machine a framework.workflows
• Les callbacks deviennent des event subscribers ecoutant les evenements workflow.transition
• Les guards utilisent le langage d'expression de Symfony au lieu de callbacks de services
• Le composant Workflow a un meilleur outillage : la commande workflow:dump genere des diagrammes visuels

Note : le package winzou/state-machine-bundle a ete deplace dans les dependances suggerees de Sylius 2.0 et peut toujours etre installe manuellement, mais tous les workflows core de Sylius ont migre vers Symfony Workflow.

Symfony UX remplace jQuery

La migration frontend n'est pas qu'une decision Sylius : elle s'aligne avec la direction de l'ecosysteme Symfony. Symfony UX (Turbo + Stimulus) est l'approche officielle pour l'interactivite frontend dans les applications Symfony.

Pour les developpeurs Sylius, cela signifie :

• Plus de dependance jQuery
• Les fonctionnalites interactives utilisent des controllers Stimulus au lieu de JS inline
• Les mises a jour de page utilisent Turbo Frames et Streams pour des rafraichissements partiels
• Le pipeline d'assets change (mise a jour de la configuration Webpack Encore ; Sylius 2.0 utilise toujours Webpack Encore)

API Platform 4

Sylius 2.0 passe d'API Platform 2.7 a API Platform 4, ce qui apporte :

• Configuration des resources simplifiee (nouveau schema XML metadata/resources-3.0)
• State providers et processors remplacant les anciens data providers et data persisters
• Generation amelioree de la documentation OpenAPI
• Support ameliore de JSON:API et GraphQL au niveau API Platform (note : Sylius 2.0 n'expose pas d'endpoints GraphQL par defaut, mais vous pouvez les activer)

Si vous avez ecrit des data providers, data persisters ou data transformers API Platform custom, ils devront etre reecrits en state providers, state processors ou serializer context builders. Les namespaces changent en consequence (par exemple, les classes sous Sylius\Bundle\ApiBundle\DataProvider se deplacent vers Sylius\Bundle\ApiBundle\StateProvider). Sylius prefixe egalement tous ses groupes de serialisation avec sylius: en 2.0, donc toute resource custom qui etend les groupes Sylius doit etre mise a jour.

Chemin de migration pratique

Voici l'approche que je recommande :

Phase 1 : Preparation sur Sylius 1.x (1-2 semaines selon l'etat du projet)

Avant de toucher a Sylius 2.0, nettoyez votre codebase actuelle :

• Montez sur la derniere release Sylius 1.x (1.14 LTS si ce n'est pas deja fait)
• Lancez PHPUnit avec SYMFONY_DEPRECATIONS_HELPER=strict
• Corrigez toutes les deprecations Symfony : encoders vers password hashers, annotations vers attributs, SwiftMailer vers symfony/mailer
• Assurez-vous que vos tests passent au vert

Phase 2 : Audit (1-2 jours)

Lancez un audit complet de votre projet pour comprendre le perimetre complet de la migration :

• Comptez les overrides de templates
• Listez les personnalisations de state machines winzou
• Verifiez la compatibilite des plugins
• Inventoriez les personnalisations frontend

C'est la que Sylius Upgrade Analyzer aide. L'outil CLI automatise l'ensemble de cet audit, scannant votre codebase avec 49 analyseurs organises en 5 familles thematiques et produisant un rapport avec des estimations d'effort. Il tourne localement, votre code ne quitte pas votre machine.

Phase 3 : Migration backend (1-4 semaines)

Attaquez les changements backend par ordre de dependance :

1. Mettez a jour composer.json pour requierir Sylius 2.0
2. Migrez la configuration et les callbacks de state machines
3. Mettez a jour les integrations de passerelles de paiement
4. Corrigez les usages d'APIs depreciees restants

Phase 4 : Migration frontend (1-4 semaines)

Cela peut souvent tourner en parallele du travail backend :

1. Remplacez les classes Semantic UI par Bootstrap 5
2. Convertissez le code jQuery en controllers Stimulus
3. Mettez a jour la configuration de build des assets
4. Testez toutes les fonctionnalites interactives (panier, checkout, admin)

Phase 5 : Mise a jour des plugins & QA (1-2 semaines)

Mettez a jour tous les plugins, lancez les tests de regression complets, et validez les flux de paiement. Rappelez-vous que la compatibilite des plugins varie : certains (comme plusieurs plugins BitBag) ont deja des releases stables 2.x, d'autres sont encore en cours de portage.

Conclusion

Symfony 7 + Sylius 2.0 est une modernisation majeure. Le stack resultant est plus propre, plus maintenable, et mieux aligne avec la direction de l'ecosysteme PHP. L'effort de migration est reel mais gerable avec une planification appropriee.

Le plus gros risque n'est pas un changement individuel : c'est de sous-estimer le perimetre combine. Auditez d'abord, planifiez methodiquement, et vous en sortirez avec une bien meilleure codebase.