Symfony - Ce que j'aurais aimé savoir plus tôt

Retrouvez l'article original sur duboiss.fr/blog/symfony-ce-que-j-aurais-aime-savoir-plus-tot.

Cet article regroupe un ensemble d'éléments, d'options ou de pratiques que j'aurai aimé connaître plus tôt lorsque j'ai commencé l'apprentissage du framework Symfony.

Certaines touchent au framework même, tandis que d'autres gravitent autour.

J'ai préféré découper par point, l'ordre étant totalement arbitraire.

Cheat Sheets

Andréia Bohner a réalisé plusieurs cheat sheets symfony.
Si vous n'êtes pas branché documentation ou souhaitez simplement conserver des condensés sur des thèmes bien précis, vous trouverez de belles feuilles.

Performance

Il existe une documentation sur la performance, peut-être bien pas assez mise en avant.

Je vous conseille notamment l'augmentation du cache realpath dans la configuration PHP, même en développement.
Cela a pour mon cas amélioré drastiquement les performances quand je travaillais sous windows.

Note à part, l'utilisation de symfony check:req peut également vous donner des indications.

framework.yaml

Il existe une clé IDE permettant de spécifier l'éditeur/IDE utilisé pendant le développement (phpstorm, vscode...).

# config/packages/framework.yaml
framework: 
    ide: 'phpstorm'

Celle-ci permet d'améliorer l'expérience développeur en proposant des liens d'ouverture rapide dans l'IDE depuis le profiler.

monolog.yaml

Pour les logs de production, il peut être laborieux d'avoir un gigantesque fichier prod.log.

C'est là qu'interviennent deux clés, type et max_files.

# config/packages/prod/monolog.yaml
monolog:
    handlers:
        main:
            type:  rotating_file
            path:  '%kernel.logs_dir%/%kernel.environment%.log'
            level: debug
            # max number of log files to keep
            # defaults to zero, which means infinite files
            max_files: 10

Vous pouvez paramétrer monolog pour qu'il crée un fichier par jour avec type: rotating file et même spécifier une limite sur le nombre de fichiers à conserver avec max_files.

NotCompromisedPassword

Il existe une règle de validation NotCompromisedPassword vérifiant que le mot de passe n'est pas répertorié sur haveibeenpwned.com.

Néanmoins je ne recommande pas forcément de l'utiliser. Cela peut provoquer un ralentissement perceptible de la réponse (appel API) et si le service est down ne pas faire cette vérification.

composer.json - config.platform

Il existe une clé config.platform dans le fichier composer.json.

"config": {
    "platform": {
        "php": "7.2.5"
    },
    // ...
},

Dans cet exemple, elle indique à composer de faire comme si nous utilisions la version 7.2.5 lors de l'installation de dépendances, même si la version php du path est supérieure.

Admettons que le serveur de production utilise php 7.2.5 et que notre machine locale utilise php 7.4.1. Avec ce paramètre, on s'assure de ne pas télécharger des paquets qui fonctionneraient sur la 7.4.1 mais exploseraient sur la 7.2.5 (donc lors de la mise en production) !

Comme la documentation l'explique, on peut donc "émuler" la version de PHP utilisée.
Par cohérence, il est intéressant d'utiliser la même version que la clé require.

"require": {
    "php": "^7.2.5",
    // ...
},
"config": {
    "platform": {
        "php": "7.2.5"
    },
    // ...
},

Pourquoi est-ce d'autant plus intéressant dans un projet Symfony ? Parce que nos projets ont généralement plus d'une centaine de dépendances...

Api Platform

Envie de consulter rapidement les données depuis votre navigateur ? Ajoutez simplement l'extension désirée à la fin de l'url.

Par exemple, si vous avez une entité "User", vous avez accès aux urls /api/users.json et api/users.jsonld.

Makefile

Certains connaissent, d'autres non. Pour ma part j'ai découvert ce fichier d'automatisation avec Symfony.
Et comme je m'en sers tous les jours (gain de temps énorme), il mérite sa place.
A ce sujet, j'ai partagé SymMakefile pour les besoins les plus communs dans un projet Symfony et j'ai soumis une PR sur maker-bundle pour ajouter la prise en charge d'un générateur de Makefile.

Il s'agit ni plus ni moins d'un fichier répertoriant différentes commandes pour un projet.
On peut effectuer plusieurs actions avec une seule commande.

Pour illustrer ceci, avec un make install nous pourrions installer les dépendances PHP & Node.js, construire les assets (et pourquoi pas lancer le serveur web).
En changeant de branche git, une fois encore make install, celui-ci ne reconstruirait les dossiers vendor ou node_modules uniquement si besoin !

Utilisateurs Windows, vous pouvez aussi l'utiliser.

Linters

Il existe divers linters disponibles avec bin/console.

# Analyse le dossier "templates" en environnement de production (nécessite twig)
lint:twig templates -e prod

# Analyse les fichiers xliff dans "translations"
lint:xliff translations

# Analyse les fichiers yaml dans "config" et "translations"
lint:yaml config translations

# Vérifie les services dans le container
lint:container

lint:container est le petit dernier et nécessite au moins Symfony 4.4

Commandes

Il n'est pas obligatoire de rédiger les commandes entièrement.
Nous pouvons très bien utiliser bin/console d:d:c à la place de bin/console doctrine:database:create.

Cependant, attention. En fonction de la saisie, le binaire peut ne pas être en mesure de savoir quelle commande appeler.

Exemple avec le maker bundle. bin/console m:v, aujourd'hui la commande peut faire référence à maker:validator ou make:voter.
Vous devrez donc être plus explicite et utiliser bin/console m:va ou make:vo.

Il n'est donc pas recommandé d'utiliser ces "raccourcis" dans des scripts externes.

bin/console -v

bin/console -V retourne la version symfony de l'application ainsi que APP_ENV et APP_DEBUG.

Symfony 5.2.1 (env: dev, debug: true)

Il est donc inutile d'ouvrir un fichier dans un éditeur pour connaître ces informations.

Conclusion

Certaines astuces peuvent nous rendre plus productifs. Autant en profiter.

En espérant que l'un de ces points vous étiez inconnu !