Le problème de l’autowiring

Avant 3.3, le DI de Symfony était puissant mais verbeux. Chaque service devait être déclaré explicitement dans services.yml avec ses arguments listés. L’autowiring existait depuis 3.1, mais il était opt-in par service et avait assez de cas limites pour vous mordre. Les équipes écrivaient soit des montagnes de YAML, soit s’appuyaient sur des bundles tiers pour réduire le bruit.

3.3 a réécrit les defaults. Avec autoconfigure: true et autowire: true définis une seule fois dans la section defaults, chaque classe dans src/ devient automatiquement un service, et ses dépendances de constructeur sont résolues par type. Ce qui prenait vingt lignes de YAML ne prend maintenant plus rien :

services:
    _defaults:
        autowire: true
        autoconfigure: true
    App\:
        resource: '../src/'

Ce bloc unique est toute la configuration de services pour la plupart des applications. Le framework découvre les services, injecte les dépendances, et applique les tags (command, event subscriber, voter…) en fonction des interfaces que chaque classe implémente.

Les conditionnels instanceof

Le mot-clé instanceof dans la configuration des services gère le tagging qui nécessitait auparavant une déclaration explicite :

services:
    _instanceof:
        Symfony\Component\EventDispatcher\EventSubscriberInterface:
            tags: ['kernel.event_subscriber']

Tout service implémentant EventSubscriberInterface reçoit le tag automatiquement. Même chose pour Command, Voter, MessageHandlerInterface. Le boilerplate s’évapore.

Le composant Dotenv

Avant 3.3, Symfony n’avait aucun moyen natif de charger des fichiers .env. La réponse standard était un package tiers. Le nouveau composant Dotenv lit .env et peuple $_ENV et $_SERVER, faisant de la configuration basée sur l’environnement un citoyen de première classe enfin.

Découverte des services depuis le filesystem

L’option resource rassemble tout. Au lieu d’enregistrer chaque classe individuellement, on pointe le conteneur vers un répertoire et il scanne les classes PSR-4 :

services:
    App\:
        resource: '../src/'
        exclude: '../src/{Entity,Migrations}'

Chaque classe trouvée devient un service avec son FQCN comme service ID. L’option exclude gère les cas comme les entités Doctrine qu’on ne veut pas que le conteneur touche. Et non, ce n’est pas de la magie : c’est un scan filesystem à la compilation, donc le coût est payé une fois pendant le cache warmup, pas par requête.

Quand on a besoin d’un sous-ensemble du conteneur

Les service locators résolvent une tension spécifique : certains services ont légitimement besoin d’accéder de manière paresseuse à un ensemble variable d’autres services, mais injecter le conteneur entier est un anti-pattern — ça masque les dépendances et déjoue l’analyse statique. La solution est un locator qui déclare explicitement ce qu’il contient.

services:
    App\Handler\HandlerLocator:
        class: Symfony\Component\DependencyInjection\ServiceLocator
        tags: ['container.service_locator']
        arguments:
            -
                App\Command\CreateOrder: '@App\Handler\CreateOrderHandler'
                App\Command\CancelOrder: '@App\Handler\CancelOrderHandler'

    App\Bus\CommandBus:
        arguments: ['@App\Handler\HandlerLocator']

Le locator implémente ContainerInterface de PSR-11, donc la classe réceptrice type-hinte contre Psr\Container\ContainerInterface. Les services à l’intérieur sont instanciés de manière paresseuse : si un handler donné n’est jamais appelé pendant une requête, il n’est jamais construit.

Et à propos de PSR-11 : Symfony 3.3 a fait implémenter ce standard à son conteneur. Ce qui signifie que toute bibliothèque attendant un conteneur PSR-11 fonctionne maintenant directement avec le conteneur Symfony, sans adaptateur.

Le routing est devenu plus rapide

Le composant de routing a réécrit comment il génère les fichiers dump. Dans une application avec 900 routes, la correspondance d’URL est passée de 7,5 ms à 2,5 ms par correspondance : une réduction de 66%. Les optimisations vivent dans la sortie compilée, pas dans le chemin d’exécution, donc les définitions de routes existantes en bénéficient automatiquement après un cache clear.

Trouver la racine du projet sans compter les séparateurs de répertoires

Avant 3.3, obtenir la racine du projet nécessitait le pattern délicieusement maladroit %kernel.root_dir%/../, parce que getRootDir() pointait vers le répertoire app/. La nouvelle méthode getProjectDir() remonte depuis le fichier kernel jusqu’à trouver composer.json et retourne ce répertoire.

// Avant
$path = $this->getParameter('kernel.root_dir') . '/../var/data.db';

// Après
$path = $this->getParameter('kernel.project_dir') . '/var/data.db';

Le paramètre correspondant est %kernel.project_dir%. Si vous déployez sans composer.json, vous pouvez surcharger la méthode dans votre classe kernel et retourner n’importe quel chemin qui fait sens.

Les messages flash sans toucher l’objet session

L’ancienne façon d’itérer les messages flash dans Twig nécessitait de passer par app.session.flashbag, ce qui forçait aussi le démarrage de la session qu’il y ait des messages ou non. Le nouveau helper app.flashes évite les deux :

{% raw %}{% for label, messages in app.flashes %}
    {% for message in messages %}
        <div class="flash-{{ label }}">{{ message }}</div>
    {% endfor %}
{% endfor %}{% endraw %}

S’il n’y a pas de messages flash, la session ne démarre jamais. On peut aussi filtrer par type : app.flashes('error') ne retourne que les messages d’erreur.

La commande encode-password est devenue intelligente

La commande console security:encode-password est devenue plus futée. Au lieu d’exiger qu’on passe la classe utilisateur en argument, elle liste maintenant les classes utilisateur configurées et laisse choisir :

$ bin/console security:encode-password

  For which user class would you like to encode a password?
  [0] App\Entity\User
  [1] App\Entity\AdminUser

Elle normalise aussi la configuration des encodeurs pour gérer les cas limites avec des noms d’utilisateur au format email que la version précédente corrompait silencieusement en remplaçant @ par des underscores. Beau rattrapage.

HTTP/2 push et resource hints

Le composant WebLink gère l’en-tête HTTP Link, qui dit aux navigateurs (et aux proxies HTTP/2) de précharger, prérécupérer ou se préconnecter à des ressources avant même que la page les demande. Il se présente sous forme de fonctions Twig :

{% raw %}{{ preload('/fonts/custom.woff2', { as: 'font', crossorigin: true }) }}
{{ prefetch('/api/next-page-data.json') }}
{{ dns_prefetch('https://fonts.googleapis.com') }}{% endraw %}

Chaque appel ajoute un en-tête Link correspondant à la réponse. Pour les applications derrière un proxy capable HTTP/2, ça peut déclencher un server push avant même que le navigateur ait parsé le HTML. On l’active dans config.yml :

framework:
    web_link:
        enabled: true

Des dépréciations auxquelles on peut vraiment faire confiance

La compilation du conteneur générait des avertissements de dépréciation qui disparaissaient au prochain chargement de page parce que le conteneur mis en cache était déjà construit. 3.3 persiste ces messages sur disque et les affiche dans la barre de débogage web aux côtés des dépréciations de la phase de requête. Si une classe est dépréciée pendant la compilation des services, vous le verrez sans avoir à vider le cache d’abord.

Ce que ça a signifié pour 4.0

Les defaults d’autowiring de 3.3 sont exactement ce que Symfony 4.0 a adopté comme nouvelle structure de projet standard. Le services.yaml de chaque nouveau projet Symfony 4 est essentiellement le snippet ci-dessus. Si on avait déjà assimilé ce que 3.3 introduisait, le “nouveau mode” de 4.0 semblait familier plutôt qu’étranger.

La direction était claire : moins de configuration, plus de convention. Laisser PHP comprendre ce qu’il faut câbler ensemble.