![AFUP](assets/afup-logo-full-color.svg?sluv=local)

Alexandre Rock Ancelelet PHP / Symfony trainer Follow me `@pierstoval` **(everywhere)**

Quoi de neuf dans le monde de Symfony ?

Programme:

* Quelques rappels sur Symfony

* De Symfony 1 à Symfony 2

* La BC promise de Symfony 2.3

* De Symfony 2 à Symfony 3

* De Symfony 3 à l'avenir

* Flex & Symfony 4

Quelques rappels sur Symfony

* Framework PHP open-source

* Framework orienté HTTP

* Plus de 45 composants

* Licence MIT

* Entre 7 et 8% des entreprises dans le monde l'utilisent

* _Touche française_ 🥐

Symfony 1 (v1.0.0 : Octobre 2005)

* PHP 5.2.4+

* Utilisation d'un contexte statique _(Singleton)_

* Plugins réutilisables _(mais assez fermés au reste de l'application)_

* Pas de gestion de dépendances _(Composer v1.0.0-alpha1 : Mars 2012, premier commit un an plus tôt)_

* Complexité parfois élevée _(formulaires, surcharge dans les plugins, etc.)_

Symfony 2 (v2.0.0 : Juillet 2011)

* PHP 5.3.2+ (arrivée des namespaces & closures)

* Framework HTTP

* Remplacement du contexte par un DIC (Dependency Injection Container)

* "Plugins" deviennent "Bundles", beaucoup plus flexibles

* Simplification / réécriture d'une très grande partie du code de Symfony 1

* Gestion des dépendances avec des submodules `git` pour la v2.0

* Sortie de v2.1.0 en Septembre 2012 et intégration de Composer

La _"BC promise"_

* Commence à la v2.3.0 (Juin 2013)

* BC (Backward compatibility) = Rétrocompatibilité

* Rétrocompatibilité systématique suivant [Semver](http://semver.org/)

* Les interfaces et l'annotation `@api` définissent le contrat de rétrocompatibilité

* Migrations vers des versions ultérieures simplifiées

* Déprécations visible dans le profiler & les logs

* À partir de la v2.7.0 (Mai 2015), le PHPUnitBridge affiche lui aussi les déprécations

Source: http://symfony.com/doc/current/contributing/code/bc.html

Symfony 3 (v3.0.0 : Novembre 2015)

* PHP 5.5.9+ (générateurs, syntaxe `MyClass::class`)

* Suppression de TOUTES les déprécations de la v2

* Optimisation de fonctionnalités pour les composants **Console**, **DependencyInjection**, **Yaml**, **Form**, **Translator**, **VarDumper**, **Security**, pour les tests...

* Grosse mise à jour du composant **Form**

* Nouvelle architecture de dossiers

* Nouveautés issues de la v2.8:

* Nouveaux composants: **PropertyInfo**, **Guard**, **LDAP** et les différents **Polyfills**.

* Nouveau design du profiler, de la debug toolbar et de la console

* **MicroKernel** (pour utiliser Symfony comme micro-framework)

* **Autowiring**

De Symfony 3 à l'avenir,
Les nouveautés de Symfony 3.1 et 3.2

* Nouveaux composants: **Cache** (avec [PSR-6](http://www.php-fig.org/psr/psr-6/)), **Workflow**

* **DateTimeNormalizer** et **DataUriNormalizer** pour le Serializer

* Amélioration du composant Yaml (nouvelles specs Yaml 1.2)

* Améliorations générales de plusieurs composants: **Security**, **Console**, **Yaml**, **Cache**, **Filesystem**, **HttpFoundation**...

* Support d'Unicode dans le routing

* Variables d'environnement dans la configuration (Yaml : `my_param: %env(MY_ENV_VAR)%`)

De Symfony 3 à l'avenir, l'explosion de Symfony 3.3
(v3.3.0 : fin Mai 2017)

La version qui comporte le plus de nouveautés depuis la 2.3 (plus de 40 !) :

* Service locators * Service autoconfiguration * Persisted deprecation logs * **WebLink** component * **SecurityBundle** improvements * Redesigned exception pages * Faster routing * A simpler way to get the project root directory * Improved flash messages * **Workflow** improvements * Deprecated the special `SYMFONY__` env vars * `about` command * Better handling of command exceptions * `Lock` component

* Load config files with glob patterns * Deprecated cache clear with warmup * Simpler service configuration * `Kernel::build()` Method * Deprecated `X-Status-Code` * Deprecated the `ClassLoader` component * Manifest-based asset versioning * Asset preloading with HTTP/2 Push * XLIFF linter * Getter injection * Deprecated the autowiring types * Import config files with glob patterns * Custom YAML tags * PSR-11 containers

* Automatic `Console` logging * Simple Cache * `Dotenv` component * `Dependency Injection` deprecations * Memcached Cache Adapter * Search in dumped contents * Optional class for named services * WebServerBundle * Cookie improvements * Improved command descriptors * Added new shortcut methods * Improved the Profiler configuration panel * Support for form action & method attributes * JSON authentication

Nouveautés de Symfony 3.3
(parmi mes préférées)

* Nouveaux composants : **DotEnv**, **Lock**, **WebLink**, **WebServerBundle**

* Authentification JSON

* Classe en tant qu'id de service

* Simple cache (avec [PSR-16](http://www.php-fig.org/psr/psr-16/))

* Assets preload & HTTP/2 Push

* Assets basés sur un "manifeste" JSON

* Paramètre `%kernel.project_dir%`

* Autoconfiguration de services

Symfony 4 (v4.0.0 : Novembre 2017)

* PHP 7.1+ * 5.6 : args variadiques, const expr, `use function|const` * 7.0 : return types, scalar typehints * 7.1 : const visibility, nullables...

* Suppression de TOUTES les déprécations de la v3

* Intégration avec Flex

* Nouvelle architecture de dossiers

* L'édition Standard de Symfony ([`symfony/symfony-standard`](https://github.com/symfony/symfony-standard/)) sera (certainement) modifiée pour automatiquement utiliser Flex

Flex

Avant Flex

1
$ composer create-project symfony/standard-edition my_project
1
$ symfony new 3.2 my_project

Situation : * Tout est installé par défaut (Monolog, Twig, Swiftmailer) * Pas de workflow frontend par défaut (avant, il y avait Assetic) * Installation de dépendances fastidieuse (documentation, copier/coller) * Appli web clé-en-main mais trop générique

L'idée derrière Flex

Mot d'ordre: ## _Composition over inheritance_

Flex, c'est:

* Un plugin Composer (`symfony/flex`)

* Lors d'un `composer require/remove`, Flex cherche une "recette"

* Si une recette existe sur le serveur de Symfony Flex, le plugin récupère son "manifeste"

* Flex exécute toutes les actions définies par le manifeste

* Bonus : S'il n'y a pas de recette mais que `"type": "symfony-bundle"` existe dans votre `composer.json`, celui-ci est ajouté au Kernel

* Bonus 2 : Symfony Flex va créer des alias comme `cli` pour `symfony/console` ou `orm` pour toute la suite Doctrine ORM

Testez !

1
2
3
4
$ composer create-project symfony/skeleton:3.3.x-dev demo
$ cd demo
$ composer req cli
$ composer req orm

Sources: * https://github.com/symfony/skeleton * https://github.com/symfony/recipes/blob/master/symfony/console/3.3/manifest.json * https://github.com/symfony/recipes/blob/master/javiereguiluz/easyadmin-bundle/1.16/manifest.json * https://github.com/symfony/recipes/blob/master/symfony/orm-pack/2.4/manifest.json * https://packagist.org/packages/symfony/orm-pack

"Flex recipes"

Deux projets où seront stockées les recettes avec leurs manifestes: * https://github.com/symfony/recipes * https://github.com/symfony/recipes-contrib Ces projets sont utilisés par le serveur de Symfony Flex pour récupérer toutes les informations utiles afin d'installer vos packages Composer associés à une recette.

Recettes "officielles"

* Gérées et déciées par l'équipe de Symfony * Les seules à pouvoir définir un "alias"

Recettes "contributeurs"

* Gérées et déciées par la communauté (un bot peut même valider & merge les PR !) * Pas d'alias possible * Nécessite un petit ajustement à votre projet: ``` composer config extra.symfony.allow-contrib true ```

Structure de base

`symfony/skeleton` utilisant Flex permet l'utilisation de la nouvelle structure:

./
├── .env
├── .env.dist
├── .gitignore
├── composer.json
├── composer.lock
├── etc
│   ├── packages
│   │   ├── dev/
│   │   │   └── framework.yaml
│   │   ├── prod
│   │   │   └── doctrine.yaml
│   │   ├── test
│   │   │   └── framework.yaml
│   │   ├── app.yaml
│   │   ├── doctrine.yaml
│   │   └── framework.yaml
├── Makefile
├── src
│   ├── Controller/
│   └── Kernel.php
├── var
│   ├── cache/
│   └── logs/
├── vendor
└── web
    ├── bundles/
    └── index.php

### Avantages et nouveautés : * Utilisation de **variables d'environnement** * Un **MicroKernel** au lieu d'un Kernel complet * Configuration chargée par des chemins "glob" * Plus de bundle par défaut, tout est dans `src/` * Config des dépendances dans `etc/packages/` * Un `Makefile` pour les commandes, Symfony ou autre * Un seul point d'entrée web: `index.php`

Flex packs

Flex encourage la création de "packs" sur Packagist.

Un Pack est juste un fichier `composer.json` avec des instructions `require`, rien de plus.

Exemple : https://packagist.org/packages/symfony/orm-pack

{
    "name": "symfony/orm-pack",
    "type": "metapackage",
    "license": "MIT",
    "description": "A pack for the Doctrine ORM",
    "require": {
        "php": "^7.0",
        "doctrine/orm": "^2.4.5",
        "doctrine/doctrine-bundle": "^1.6"
    },
    "extra": {
        "branch-alias": {
            "dev-master": "2.4.x-dev"
        }
    }
}

Recette du DoctrineBundle : https://github.com/symfony/recipes/tree/master/doctrine/doctrine-bundle/1.6

Avantages des packs

Comme d'habitude avec Flex, si un package possède une recette, elle sera récupérée.

Grâce au package `symfony/orm-pack` et à sa recette, pour installer Doctrine ORM & toute la config nécessaire, il suffit d'exécuter cette commande :

1
composer req orm

Flex skeletons

Pour créer un projet Symfony, nous utilisons ce code avec Flex: #### `composer create-project symfony/skeleton my_project`

`symfony/skeleton` n'est rien d'autre qu'un **pack** qui a Flex pour dépendance.

Chaque dépendance de ce projet sera installée et vu que Flex est la première, celle-ci va automatiquement détecter les recettes de toutes les autres dépendances.

On peut ainsi imaginer tout un tas d'applications clé-en-main:

1
2
3
4
5
6
7
composer create-project symfony/skeleton-cms
composer create-project symfony/skeleton-ecommerce
composer create-project symfony/skeleton-blog
composer create-project symfony/skeleton-microservice
composer create-project symfony/skeleton-cli

(ces packages n'existent pas, mais l'idée est là)

Ce que permet donc Flex...

Toujours ce même mot d'ordre : _**Composition over inheritance**_

On **compose** notre application en fonction de nos besoins.

On ne crée plus une application "prête-à-l'emploi" contenant parfois trop de composants.

Flex est compatible avec **tout package Composer**, pas seulement avec Symfony. On peut créer des recettes pour tout un tas d'autres projets !

Sauf Laravel ![troll](assets/trollface.png?sluv=local)

Merci à tous. Questions?


@pierstoval