Symfony : Une genèse majeure

Connaissez-vous la phrase "Celui qui ne sait pas d'où il vient ne peut savoir où il va" ?
Ou celle-là encore "Dans un voyage ce n'est pas la destination qui compte mais toujours le chemin parcouru, et les détours surtout".

Alors que la première release de Symfony 6.x vient de sortir, je vous propose un petit travail de mémoire.
Mélange d'histoire et d'anecdotes choisies de 11 ans d'expérience avec le framework.

Symfony 1.x

Introduction

Symfony est né chez SensioLabs, une société de service Française.
Comme toutes les boites à cette époque, elle a développé son framework maison.
À la manœuvre, on retrouve évidemment l'incontournable Fabien Potencier.
Bien qu'il n'était pas le seul à travailler dessus, on lui doit une bonne partie du framework (encore aujourd'hui).

Souvenirs

Nous sommes donc dans les années 2000, et SVN est le standard du versioning.
Évidemment le repository de l'époque (svn.symfony-project.com) n'existe plus.
Mais un miroir Git est toujours disponible si vous êtes nostalgique.

Et la documentation est toujours accessible via son URL d'origine : symfony-project.com.

Apparence

Et donc, une application Symfony 1.4, ça ressemble à quoi ?

├── apps
│   └── frontend
│       ├── config
│       ├── i18n
│       ├── lib
│       ├── modules
│       └── templates
├── cache
├── config
│   ├── databases.yml
│   ├── doctrine
│   │   └── schema.yml
│   ├── ProjectConfiguration.class.php
│   ├── properties.ini
│   └── rsync_exclude.txt
├── data
│   └── fixtures
│       └── fixtures.yml
├── lib
│   ├── form
│   │   └── BaseForm.class.php
│   └── vendor
│       └── symfony
├── log
├── plugins
├── symfony
├── test
│   ├── bootstrap
│   ├── functional
│   └── unit
└── web
    ├── css
        └── main.css
    ├── frontend_dev.php
    ├── images
    ├── index.php
    ├── js
    └── uploads

Il faut se souvenir qu'à cette époque, il n'y a pas de package manager pour PHP.
Donc les librairies sont généralement téléchargées, désarchivées et versionnées manuellement dans le projet.
On ne parle pas encore de bundle, mais de plugin, et il y en a quelques-uns de fameux : sfGuardPlugin, sfPropelORMPlugin, ...

AdminGenerator

À ce moment de l'histoire, Symfony embarque nativement un composant d'administration : l'admin generator

Pour la petite histoire : c'est parce que ce composant était natif en 1.4 mais pas en 2.0 que SonataAdminBundle se décrit comme "The missing Symfony Admin Generator".

Jobeet

Comment ne pas parler de cette version de Symfony sans mentionner Jobeet ?
Tous ceux qui ont un jour développé sur du 1.4 ont connu ce fameux tuto en 23 jours.

Pour la petite histoire : aujourd'hui, SymfonyCasts a pris le relais de Jobeet.
Mais à l'époque où Symfony 2 est sorti, plusieurs tentatives individuelles ont vu le jour pour combler ce "manque" : en français ou en anglais

La mort de la v1

Symfony 1.x s'est éteint en novembre 2012. Remplacé par son logique, mais très différent, successeur.

Mais vous ne savez peut-être pas qu'une version 1.5 de Symfony existe bel et bien.

J'adore cette initiative car elle est très représentative de ce qu'il s'est passé à l'époque.
L'arrivée de Symfony 2.0 a réellement bouleversé l'écosystème PHP.
Et tous ceux qui ne pouvaient se permettre la mise à jour ont cherché des solutions pour profiter de certaines des nouveautés les plus utiles, comme Composer ou l'injection de dépendance.

Symfony 2.x

Une refonte totale

Cette version majeure n'a absolument rien à voir avec la version précédente.
Peu importe votre expérience en la matière, vous deviez tout reprendre de zéro.

De la structure de dossier, à la philosophie générale du framework, en passant par le logo ou encore le site, tout à été revu.

La nouveauté la plus structurante de cette version c'est sans nul doute le composant d'injection de dépendances et avec lui le concept de service.
Il est alors (et encore aujourd'hui) la colonne vertébrale de Symfony.

Une 2.0 encore en devenir

Cette première version a beau révolutionner la précédente, elle n'en reste pas moins très différente des versions qui vont suivre.

Pour créer un nouveau projet Symfony alors, on clone symfony/symfony-standard pour en faire son propre repository.

├── app
│   ├── AppCache.php
│   ├── AppKernel.php
│   ├── autoload.php
│   ├── check.php
│   ├── config
│   │   ├── config_dev.yml
│   │   ├── config_prod.yml
│   │   ├── config_test.yml
│   │   ├── config.yml
│   │   ├── parameters.ini
│   │   ├── routing_dev.yml
│   │   ├── routing.yml
│   │   └── security.yml
│   ├── console
│   ├── logs
│   ├── phpunit.xml.dist
│   └── Resources
│       └── views
├── bin
│   └── vendors
├── deps
├── deps.lock
├── src
│   └── Acme
│       └── DemoBundle
├── vendor
└── web
    ├── app_dev.php
    ├── app.php
    └── config.php

La principale différence avec les versions suivante, c'est l'absence de Composer.
Et oui, au moment où Symfony 2.0 sort, Composer n'existe pas encore (il n'est pas si lointain, mais pas encore utilisable)

A ce moment là, on utilise un fichier deps et un fichier deps.lock (oui, ce n'est pas si éloigné) et on utilise le script fourni avec le framework bin/vendors install pour installer les dépendances.

Pour la petite histoire : Lorsque Composer est passé stable (des années après), Jordi Boggiano (aka seldaek) a immortalisé cette release avec une disquette dorée contenant le code source, mise en vente sur eBay.

Le chemin vers la 2.3

Cette version peaufine et assume les changements faits jusque là, bien qu'il n'y ait pas eu de révolution.
Le fichier parameters.ini a été remplacé par un fichier parameters.yaml.dist, et le plugin incenteev/composer-parameter-handler gère sa copie en demandant à l'utilisateur de valider chaque paramètre (vous souvenez-vous avoir laissé la touche entrée enfoncée plusieurs secondes ?).

La fin de la 2.x avec la 2.8

Cette version signe la fin du cycle 2.x.
Si vous avez pris Symfony en cours de route à partir de la v3, vous-vous demandez peut-être pourquoi Symfony ne s'est pas arrêté à la 2.4.

Et bien c'est à ce moment-là que Symfony a décidé de se projeter sur un cycle de release prévisible, avec des règles claires - il n'y a que 5 versions par majeure : x.0, x.1, x.2, x.3, x.4 - la version x.0 est l'égale de la version {x-1}.4, mais tout ce qui est déprécié a été supprimé - entre la version 0 & la version 4, rien ne doit être cassé mais déprécié - la version 4 est une LTS et sera supportée entre 3 et 4 ans (selon le type de bug)

Ce process de release a d'ailleurs été bien documenté sur le site de Symfony.

Pour la petite histoire : Symfony 2.0 est sorti en juillet 2011 & le support de Symfony 2.8 s'est arrêté en novembre 2019. 8 ans...

Symfony 3.x

La version 3.x n'apporte pas énormément de changement, si ce n'est la fin de la consigne "découpez votre code en bundle".
Même si dans l'idée c'était une bonne chose de vouloir découper son code en fragments ré-utilisables, pour les projets ça posait beaucoup plus de problème que ça n'en résolvait.
Avec cette version, est arrivé le bundle unique AppBundle (ce n'est qu'une convention) destiné à contenir l'ensemble des sources de l'application.

├── app
│   ├── AppCache.php
│   ├── AppKernel.php
│   ├── config
│   │   ├── config_dev.yml
│   │   ├── config_prod.yml
│   │   ├── config_test.yml
│   │   ├── config.yml
│   │   ├── parameters.yml.dist
│   │   ├── routing_dev.yml
│   │   ├── routing.yml
│   │   ├── security.yml
│   │   └── services.yml
│   └── Resources
│       └── views
├── bin
│   ├── console
│   └── symfony_requirements
├── composer.json
├── composer.lock
├── phpunit.xml.dist
├── src
│   └── AppBundle
├── tests
├── var
│   ├── cache
│   ├── log
│   ├── sessions
│   └── SymfonyRequirements.php
├── vendor
└── web
    ├── app_dev.php
    ├── app.php
    └── config.php

Symfony 4.x

Cette version est l'avènement de symfony/flex.
L'objectif de flex, comme l'explique Fabien sur son blog est d'automatiser certaines opérations de l'installation de packages, et permettre un écosystème de projets Symfony plus modulaires que jusqu'alors.

En effet, jusqu'à présent, quand on faisait un projet Symfony "full stack", le projet avait une dépendance à symfony/symfony, et contenait donc tous les composants et tous les bundles distribués en standard.
Le problème principal étant que, comme un service ayant une dépendance au conteneur, on ne peut pas d'un coup d’œil savoir de quoi ce projet a réellement besoin.

Sur cette version donc, Symfony a beaucoup travaillé à rendre le framework plus modulaire.
Aujourd'hui, FrameworkBundle est capable de détecter la présence de certains composants et de s'adapter en fonction.

Avec cette modularité est arrivée la nécessité de repenser la façon de démarrer un nouveau projet.
Jusqu'alors, on démarrait en utilisant symfony/framework-standard-edition.
Ce repository contient toute la structure d'une application Symfony, mais tout ça n'est plus nécessaire grâce à flex.

Aujourd'hui, si vous voulez démarrer un nouveau projet, vous allez utiliser symfony/skeleton.
Ce repository m'a toujours beaucoup amusé, car il s'agit d'un bête fichier composer.json avec la liste des packages nécessaires à l'installation.
Flex s'occupant d'appliquer les "recettes" d'installation depuis son repository de recettes.

La nouvelle structure de dossier reflète cette nouvelle modularité.

├── bin
│   └── console
├── composer.json
├── composer.lock
├── config
│   ├── bootstrap.php
│   ├── bundles.php
│   ├── packages
│   │   ├── cache.yaml
│   │   ├── framework.yaml
│   │   ├── prod
│   │   │   └── routing.yaml
│   │   ├── routing.yaml
│   │   └── test
│   │       └── framework.yaml
│   ├── preload.php
│   ├── routes
│   │   └── dev
│   │       └── framework.yaml
│   ├── routes.yaml
│   └── services.yaml
├── public
│   └── index.php
├── src
│   ├── Controller
│   └── Kernel.php
├── symfony.lock
├── var
│   ├── cache
│   └── log
└── vendor

Pour la petite histoire : lorsque la nouvelle procédure d'installation a été révélée, plusieurs développeurs ont trouvé fastidieux de devoir demander tous les packages un par un, là ou avant il pouvaient se contenter d'utiliser symfony/symfony.
De cette inquiétude est néé un deuxième skeleton, contenant la quasi-totalité des dépendances standard : symfony/website-skeleton.

Symfony 5.x

Et voilà, nous sommes en novembre 2019, Symfony 2.8 vient d'atteindre sa fin de vie, et la version 5.0 sort tout juste.

Ce serait mentir que de dire qu'il n'y a pas de changement entre la 4.x et la 5.x.
En effet, le composant sécurité à profité d'une refonte, de nouveaux composants fonctionnels ont fait leur apparition (rate limiter, uid...).

Mais rien de comparable avec les changements des versions précédentes.
Pas de révolution dans l’arborescence de fichiers, et la mise à jour de la config se fait grâce à flex.

Symfony 6.x

Et donc, qu'attendre de cette version ?

En réalité, comme pour la version 5.x, il y a des nouveautés, mais aucune révolution n'est pour l'heure prévue.
Dans les faits, les différences entre les versions vont en diminuant.
Et c'est normal, puisque le framework gagne en maturité, et ses choix d'architecture se peaufinent d'une version à l'autre.

Aucune raison alors de ne pas mettre à jour votre projet !