Symfony 4 en 10 points

Le 30 novembre 2017, une nouvelle version du Framework Symfony a été publiée et il semble que la core team a souhaité révolutionner la manière de développer grâce à une nouvelle structure et de nouveaux paradigmes.
Nous avons voulu tester pour vous cette nouvelle version de Symfony dans des projets réels avant de vous faire un retour d’expérience.

1.   C’est quoi Symfony 4 ?

La version 4 de Symfony vient juste après la version 3.3. Elle est « juste » la version 3.4 mais sans dépréciations. En d’autres termes,  Symfony 4 = Symfony 3.4 sans la couche de compatibilité.

La plupart des modifications (du processus d’installation, de la structure de répertoires à l’utilisation de bundles, en passant par le codage lui-même) ont été effectuées pour améliorer l’expérience du développeur avec le Framework.

Nous allons détailler dans ce qui suit les nouveautés de Symfony 4 mais avant tout il ne faut pas oublier que Symfony 4 nécessite au minimum la version 7.1.3 de PHP, donc pensez à bien préparer votre environnement.

2.   Quels sont les avantages de Symfony 4 ?

Le but principal de la nouvelle version de Symfony était de faciliter l’installation et la prise en main du Framework. Un gros travail sur l’installation des vendors et l’auto-configuration de bundles a été effectué.
Symfony 4 implémente un nouveau système de recettes (Recipe en anglais) qui permet de gérer directement les dépendances du bundle en cours d’installation.

Vous n’avez plus besoin de lire le README.md du bundle ou d’aller sur github pour appliquer les étapes nécessaires à l’installation du bundle. Chaque bundle possède son propre manifest de configuration. La nouvelle CLI de Symfony permet d’interpréter ces recipes et d’installer directement le bundle, sans avoir à effectuer de configuration à la main. Chaque bundle possède ses propres fichiers de configuration, ça rajoute un peu de magie au fonctionnement de Symfony 4 mais n’ayez pas peur, il reste toujours possible d’installer les bundles de l’ancienne façon. Nous recommandons toutefois aux développeurs juniors de rentrer un peu dans les détails de l’installation et du fonctionnement du Framework et de ne pas se limiter à l’outil d’installation intégré.

Ci-après quelques points qui récapitulent les gros avantages de la nouvelle version de Symfony 4 :

• Plus facile à apprendre
• Version minimaliste, Bye Bye les packages inutiles
• Fini le config.yml, plus besoin de configurer ses bundles
• Déploiement rapide et simple, le plus rapide du marché (voir sur ce lien pour un benchmark)
• Migration 3 => 4 simplifiée par le système de dépréciations
• Utilisation de la version >= 7.1 de PHP
• Installation via composer, Bye Bye Symfony installer
• Libre d’installer des packages supplémentaires.

3.   Comment s’installe un projet Symfony 4 ?

Avant la version 4 de Symfony, la création d’un nouveau projet se faisait généralement en se basant sur un outil nommé Symfony Installer, avec l’arrivée de Symfony 4 la core team a souhaité standardiser le process de démarrage d’un nouveau projet en s’appuyant sur Composer sans ajouter d’outils spécifiques.

La commande magique est la suivante :

composer create-project symfony/skeleton mydir

Composer va faire le nécessaire pour créer un dossier du projet et télécharger les dépendances associées. Il va se baser sur un composant fourni par Symfony 4 nommé Flex qui est une sorte de surcouche à composer et qui va permettre de configurer automatiquement les dépendances de notre nouveau projet.

Si vous désirez lancer la commande et installer un nouveau projet Symfony 4, vous pouvez vérifier les requirements en suivant ce lien.

4.   Pourquoi Symfony Flex ?

Symfony Flex est la nouvelle façon d’installer et de gérer les applications Symfony. En effet, ce n’est pas une nouvelle version de Symfony, mais un outil (ou une surcouche) qui remplace et améliore le programme d’installation de Symfony. Symfony Flex peut marcher sur un projet Symfony 3.3 mais devient obligatoire sur un projet Symfony 4.

En d’autres termes, Symfony Flex est un plugin Composer qui modifie le comportement des commandes require, update et remove.

Lors de l’installation ou de la suppression de dépendances dans une application compatible Flex, Symfony peut effectuer des tâches avant et après l’exécution des tâches Composer.

Lorsque Symfony Flex est installé dans l’application et que vous exécutez composer require, l’application envoie une requête au serveur Symfony Flex avant d’essayer d’installer le paquet avec Composer :

• S’il n’y a aucune information sur ce paquet, le serveur Flex ne renvoie rien et l’installation du paquet suit la procédure habituelle basée sur Composer;
• S’il existe des informations spéciales sur ce package, Flex le renvoie dans un fichier appelé « recette » et l’application l’utilise pour décider du package à installer et des tâches automatisées à exécuter après l’installation.

5.   Quelle structure pour un projet Symfony 4 ?

La version 4 de Symfony a connu un changement radical au niveau de la structuration des dossiers :

• En effet le dossier web a été modifié pour être renommé en public et le fichier app.php contenu dans ce dernier renommé en index.php.
• Le dossier app a été remplacé par le dossier etc. Il a été proposé dans la version 3 de Symfony. Après de longues discussions avec la communauté le dossier etc a changé de nom pour devenir config. Ainsi le dossier config, contient les fichiers de configuration de chacun des packages de l’application. Il est équivalent au dossier app/config de la version 3 de Symfony mais il ne contient pas les fichiers parameters.yml et parameters.dist.yml.
• La classe Kernel a été déplacée dans src. Le contenu est très différent de celui de Symfony 2. Tout d’abord, il utilise le trait MicroKernelTrait. Ensuite, il implémente la logique pour charger les bundles à partir de bundles.php et pour lire les différents fichiers de configuration de bundle.
• Un nouveau fichier .env contient la configuration pour les variables d’environnements.

6.   Symfony 4 bundle-less, pourquoi ?

Symfony 4 n’a plus de bundles dans src non plus.

Tous les fichiers se trouvent maintenant dans le répertoire src / (et ont App / namespace par défaut). Cela a un effet sur deux choses :

• Vous ne pouvez pas (par défaut) diviser votre application en bundles (ce qui est déjà une mauvaise idée, vous devriez juste le diviser, mais pas en bundles).
• Les mécanismes d’héritage (Bundle inheritance mechanisms) sont obsolètes dans 3.4 et ont été supprimés dans 4.0

Cette partie concerne les bundles internes de votre application (vos propres développements) contenus dans le dossier src.

Symfony 4 a donc été repensé dans sa structure et sa gestion pour apporter plus de facilité, d’efficacité et supprimer la plupart des contraintes du développeur, notamment relatives au paramétrage des bundles.

<?php
namespace AppController;

use ...

class TestController extends Controller
{
    /**
    * @Route("/test", name="test")
    */
    public function index()
    {
        return new Response('Welcome to your new controller!')
    }

7.   Comment installer un bundle sur Symfony 4 ?

Avant

Avant Symfony 4, l’installation d’un bundle tiers était fastidieuse, nous devions passer par toutes ces étapes :

• composer require bundle
• Ajouter une ligne dans app/AppKernel.php
• Créer la configuration dans app/config/config.yml
• Importer le routing dans app/config/routing.yml

Après

Avec Symfony 4, l’installation d’un bundle tiers est un jeu d’enfant. Il suffit juste de lancer la commande suivante :

composer require bundleName

8.   Recipes de Symfony 4, c’est quoi ?

Symfony 4 rajoute la possibilité d’utiliser des recettes (Recipes) qui correspondent à un ensemble de lignes de commandes qui seront exécutées lors de l’installation d’un bundle. En effet cela décrit comment un package doit être configuré.

Les recettes Symfony 4 sont fournies par la communauté et stockées dans deux référentiels publics :

1. Main recipe repository : C’est une liste organisée de recettes pour des paquets de haute qualité et maintenus. Symfony ne regarde que dans ce référentiel par défaut.
2. Contrib recipe repository : C’est une liste de recettes créées par la communauté. Elles sont toutes garanties pour fonctionner, mais leurs paquets associés pourraient ne pas être maintenus. Symfony vous demandera la permission avant d’installer l’une de ces recettes

9.   MakerBundle, c’est quoi ?

Symfony Maker a été développé dans le but d’aider les développeurs à créer des commandes vides, des contrôleurs, des classes de formulaire, des tests etc afin que les développeurs puissent oublier d’écrire du code standard. Ce bundle est une alternative à SensioGeneratorBundle pour les applications Symfony modernes et nécessite l’utilisation de Symfony 3.4 ou Symfony 4.

Une simple commande magique permet de l’installer :

composer require maker

Quelques exemples de l’utilisation du symfony maker bundle :

• make:command Crée une nouvelle classe de commande
• make:controller Crée un nouveau controleur
• make:entity Crée une nouvelle entité doctrine

10.   Quoi de neuf pour l’injection de dépendances Symfony 4 ?

Le composant DependencyInjection implémente un conteneur de service compatible PSR-11 qui vous permet de standardiser et de centraliser la façon dont les objets sont construits dans votre application. C’est le composant qui a changé le plus dans la version 3.4 / 4 de Symfony. Voici un tour des changements :

• Autodiscovering
• Autowiring
• Autoconfiguration
• Defaults
• Bindings
• Services taggués
• Controllers as services

Nous trouverons plus de details sur chacun d’entre eux ci-après :

Identifiant de service = nom complet de la classe

Avant

app.mailer:
class: AppBundleMailerMailer
arguments: ['@twig', '@mailer']

Après

AppMailerMailer:
arguments: ['@twig', '@mailer']

Autodiscovery + Autowiring 

Avant

AppMailerMailer:
arguments: ['@twig', '@mailer']

Après

App:
resource: '../src/*'

L’autowiring n’a rien de magique. Il est basé uniquement sur les noms de classes et des typehints

public function __construct(Persister $persister, Mailer $mailer)

{ /* ... */ }

Defaults + Autoconfiguration

services:
autowire: true [Les nouvelles fonctionnalités opt-in]
autoconfigure: true [Configure automatiquement les services]
public: false [services privés par défaut]

Bindings

Ça permet d’automatiser l’injection des paramètres

services:
# pour un service précis
AppAdminAuthenticationManager:
arguments:
$projectDir: '%kernel.project_dir%'

Services taggués

services:
AppManagerTwigManager:
arguments: [!tagged twig.extension]

Controllers as services

services:
AppController:
resource: '../src/Controller'
tags: ['controller.service_arguments']

Le tag permet d’injecter les services en paramètres de l’action. En pratique nous n’utilisons pas trop cette fonctionnalité.