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 !
Top comments (0)