Les changements majeurs à venir sur Symfony 4
18 mai 2017
Dans un précédent article, je décrivais les changements que SensioLabs allait mettre en place concernant Symfony.
Cet article a plus une vocation technique, avec un listing non exhaustif des changements majeurs que l’on pourra rencontrer dans Symfony 4.
Quelques changements significatifs
Le premier changement significatif est que Symfony 4 n’embarque que les bundles servant au ’core’. Votre application ne possède pas de Form? Pas besoin de symfony/form. Vous ne voulez pas des X bundles qui s’installent au premier ‘composer update’ ? Utilisez Symfony 4. C’est en partant de symfony/skeleton que vous pourrez avoir une instance ultra légère de Symfony.
Autre chose? Oui bien sûr ! Le code de l’application devient BundleLess. Ce qui va simplifier l’utilisation des classes dans le dossier `src/` qui seront simplement régies par le namespace ‘App’. De cette façon, SensioLabs montre encore un peu plus sa volonté de réduire la complexité visuelle des applications.
Un changement majeur, qui va faciliter la vie de beaucoup de développeurs, concerne l’installation et la configuration de bundles externes.
Symfony embarque la possibilité d’écrire des Recipes (ou “Recettes” pour les plus francophones d’entre-nous) qui correspondent à une suite de lignes de commandes (Symfony ou non), qui seront exécutées à l’installation du bundle.
Des exemples de recipes sont disponibles sur le repository symfony/recipes.
Si le contributeur du bundle a besoin d’installer des fixtures, de vider le cache ou autre action nécessaire à l’installation de son bundle, il pourra décrire ce comportement dans son fichier de Recipe. Plus besoin de lire le README.md ou autre documentation pour installer le bundle. Aussi, le fichier config.yml ne contiendra plus la configuration de tous les bundles utilisés:
Chaque bundle contient son propre dossier de configuration.
Si vous voulez en savoir plus sur cette notion de recettes, je vous renvoie vers l’article de Fabien Potencier, qui liste toutes les fonctionnalités associées à cette nouvelle fonctionnalité. Il est cependant possible d’installer les bundles de l’ancienne façon.
Des raccourcis dans la nouvelle CLI
Une autre nouveauté dans la stack, concerne les Aliases. En effet, il sera possible d’utiliser directement des bundles recommandés par Sensio. Par exemple, il y aura un raccourci pour installer un bundle d’administration :
$ composer req admin |
Cette commande va installer le bundle javiereguiluz/EasyAdminBundle de Javier Eguiluz. On retrouve tout l’intérêt de cette commande avec les “recipes” vues plus haut qui permettent d’installer le bundle très facilement.
Sensio a eu de nombreux retours concernant des développeurs et des entreprises qui indiquent ne pas avoir ni le temps ni l’envie d’éprouver des bundles. C’est dans ce cadre là que Sensio recommande (mais n’oblige en aucune façon) l’utilisation de certains bundles, pour faciliter la vie des développeurs dans leurs choix.
Encore des changements dans l’organisation des dossiers & fichiers
Si vous n’avez pas suivi les changements de Symfony 3, le dossier `bin` a remplacé le dossier `app’ et nous avons eu l’apparition d’un dossier `var`, qui va contenir les logs qui étaient dans le dossier `app’ en Symfony 2.
Avec Symfony 4, un nouveau dossier apparaît: il s’agit du dossier `templates` qui va remplacer le dossier `views`. La raison est que `View` est un concept à part entière. Le dossier `etc` remplace le dossier `app/config` et va contenir la configuration de l’instance. Cette modification sert simplement à raccourcir le chemin vers les fichiers de configuration.
D’autres changements dans la gestion des paramètres d’environnement
Pour finir, il n’y a plus de notions de parameters_[ENV] qui pointent en lien symbolique vers le bon environnement courant. Ces paramètres sont gérés comme des variables d’environnement directement exploitables. Plusieurs intérêts se présentent avec cette modification :
- Pas besoin de vider le cache au changement des paramètres
- Les variables sont indépendantes du code
Qui dit paramètres par variables d’environnement, dit plus besoin d’indiquer l’environnement pour les commandes. Il suffit juste d’indiquer APP_ENV avec l’environnement qui convient !
En conclusion
Des changements, et non des moindres, sont présents pour cette nouvelle version. Certains semblent très utiles (gestion des paramètres par environnement, une instance light en début de projet) et d’autres moins (migration des templates dans le dossier ‘templates’, installation de bundles choisie par défaut). Reste à savoir si ces changements seront agréablement accueillis.
Vous pouvez retrouver tous les blog-posts de Fabien Potencier concernant les changements et pourquoi ont-ils eu lieu. En cadeau, une vidéo Youtube de SensioLabs qui montre comment construire une API avec Symfony4:
Découvrez notre expertise Symfony
DécouvrirExpert technique