Que propose concrètement Symfony 4 ?
Symfony a été créé pour simplifier la vie des développeurs en leur évitant les tâches répétitives et rébarbatives et ainsi les aider à se concentrer sur l’application en elle-même, plutôt que sur les difficultés techniques que peut apporter la création d’une application web from scratch.
C’était déjà chose faite dans les versions précédentes du framework. Avec la version 4, SensioLabs va encore plus loin en développant des fonctionnalités essentielles qui manquaient dans les versions précédentes et en simplifiant l’arborescence des projets tout en s’adaptant aux bonnes pratiques du secteur.
SensioLabs encourage les utilisateurs de Symfony 4 à ne plus décomposer leurs applications en bundle. L’utilisation du namespace unique App pour la totalité d’une application permet de ne pas tomber dans la complexité avec des AppBundle, UserBundle, ProductBundle, etc. On peut ainsi organiser notre projet directement dans le dossier src.
Dans cette même logique, on peut voir apparaître à la racine du projet, les dossiers assets, templates, translations qui sont les dossiers des ressources principales de notre application.
Le dossier public (anciennement web) quant à lui ne contient que le fichier index.php, qui grâce à la variable d’environnement APP_ENV, va afficher la version de dev ou de prod.
Lorsque l’on parle de nouvelles versions d’un framework, on a toujours en tête la difficulté de migration d’une version précédente à la version actuelle. Il n’y a pas de solution miracle, selon la version Symfony de votre application, cela sera plus ou moins difficile. Mais si vous avez développé votre application avec la version 3.4 sans avoir utilisé de fonctionnalités ou de composants dépréciés, cela vous évitera de devoir recoder certaines parties devenues désuètes.
Si vous ne connaissez pas très bien l’arborescence Symfony 4, le plus simple est de créer un nouveau projet Symfony 4, d’ajouter les composants utilisés dans composer.js et de placer vos fichiers aux bons endroits en prenant soin de corriger les namespaces, les routes et les liens vers les templates et autres assets.
Cela peut valoir le coup si vous êtes encore en plein développement et que certaines fonctionnalités vous intéressent. Prenez garde cependant : la version de Symfony 3.4 bénéfice d’un support (bug fix) jusqu’à novembre 2020 alors que la version 4.1 n’en bénéficie que jusqu’à janvier 2019. Cela veut dire que vous devrez maintenir votre application régulièrement jusqu’à la version « long term support ». De plus, si vous avez des impératifs de stabilité et de sécurités importantes, rester sur Symfony 3.4 est le choix le plus sage pour l’instant.
Vous avez deux options lorsque vous démarrez un projet Symfony 4 : la première vous permet de démarrer avec tout ce qu’il vous faut pour créer une application web ; La seconde, beaucoup plus légère vous permet de démarrer une micro-application avec le strict minimum, sans superflu. Cette solution est adaptée pour la création de micro-services, qui n’ont pas forcément besoin de Twig ou du WebProfiler par exemple. L’installation et la configuration des composants utiles à votre micro-application sont simplifiées grâce à Symfony Flex.
Les nouveautés qui ont attirées notre attention
Symfony Flex
Flex est un plugin Composer permettant d’installer vos composants directement dans votre application. Plus besoin de les charger dans Symfony à la main grâce à l’utilisation de Recipes. Elles permettent de définir quels sont les fichiers à créer, à copier, à ignorer (.gitignore), quelles sont les commandes à lancer après l’installation. La communauté est très active et de nombreuses recettes sont disponibles.
Internationalisation des routes :
Dans la version 3.4, il fallait installer un composant tiers pour gérer l’internationalisation des URL ou se contenter d’une simple locale dans l’URL à définir sur chaque route. Avec Symfony 4, on peut définir un préfixe de langue de façon générale pour nos URL, ou même des URL totalement différentes d’une langue à l’autre. Voici un exemple de configuration de type annotation :
See the Pen WyMgoo by Aaron (@leox47) on CodePen.
Tout simplement !
Gestion des Assets avec Encore :
Symfony 4 intègre la gestion des assets avec Webpack grâce à Encore. Encore est annoncé comme un mélange entre Webpack et Mix. Il permet entre autres de simplifier la configuration de notre fichier webpack.config.js. Besoin de précompiler du SASS ou du Typescript ? Besoin de configurer un CDN ? Tout cela se fait en quelques lignes !
See the Pen GGxpaL by Aaron (@leox47) on CodePen.
Mais l’intérêt principal de Encore est qu’il peut s’intégrer dans l’environnement Symfony. Il permet, entre autres, de ne charger que certains assets selon les routes définies dans vos contrôleurs. Vous pouvez par exemple charger uniquement les styles et scripts de la partie publique de votre application sur celle-ci, alors que vous gérez également les assets d’une partie privée et d’un back-office. L’intégration des scripts dans Twig se faisant très aisément, cela permet un workflow assez efficace.
Les modules s’installent grâce à npm, ou encore plus simplement via yarn. Vous lancez facilement un build de votre configuration de dev et de prod.
Malheureusement, cela ne pouvait être parfait ! C’est la version 3 de Webpack et non la 4 qui est utilisée avec Encore pour des soucis de compatibilité avec les projets sous Webpack 2 et 3. Si vous souhaitez utiliser les nouveautés de Webpack 4, passez votre chemin pour l’instant, et installez Webpack 4 indépendamment de Symfony.
Alors, êtes-vous prêt à utiliser Symfony ?
Nous vous recommandons de vous y mettre rapidement si ce n’est pas déjà fait. La version 4 de Symfony pour vos nouveaux projets est un pari très peu risqué. Si vous connaissez Symfony, cela sera facile de travailler sur cette nouvelle version, et si vous souhaitez apprendre, la courbe d’apprentissage promet d’être beaucoup moins raide étant donné la volonté de SensioLabs à adapter ce framework php aux bonnes pratiques actuelles en termes de création d’application web.
Vos projets gagneront en durée de vie et en simplicité, vos développements seront plus efficaces et plus rentables et la migration vers la version « long term support » sera beaucoup plus simple que si vous partiez d’un projet sous Symfony 3.4.
Nous proposons également plusieurs articles liés à d’autres Frameworks et à PHP sur notre blog, n’hésitez pas à le consulter.
