Symfony - Ce que j'aurais aimé savoir plus tôt
Tags: symfony, php
Published: 2021-01-15 17:14:33

> Retrouvez l'article original sur [duboiss.fr/blog/symfony-ce-que-j-aurais-aime-savoir-plus-tot](https://www.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](https://andreiabohner.org/) a réalisé plusieurs [cheat sheets symfony](https://github.com/andreia/symfony-cheat-sheets).
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](https://symfony.com/doc/current/performance.html), peut-être bien pas assez mise en avant.

Je vous conseille notamment l'augmentation du [cache realpath](https://symfony.com/doc/current/performance.html#configure-the-php-realpath-cache) 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](https://symfony.com/doc/current/reference/configuration/framework.html#ide) permettant de spécifier l'éditeur/IDE utilisé pendant le développement (phpstorm, vscode...).
```yaml
# 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](https://symfony.com/doc/current/logging.html#how-to-rotate-your-log-files), `type` et `max_files`.

```yaml
# 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](https://symfony.com/doc/current/reference/constraints/NotCompromisedPassword.html) vérifiant que le mot de passe n'est pas répertorié sur [haveibeenpwned.com](https://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**.
```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](https://getcomposer.org/doc/06-config.md#platform) 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](https://getcomposer.org/doc/01-basic-usage.md#platform-packages).
```json
"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](https://github.com/DuboisS/SymMakefile) pour les besoins les plus communs dans un projet Symfony et j'ai soumis une [PR](https://github.com/symfony/maker-bundle/pull/774) 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`.

```sh
# 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](https://symfony.com/blog/new-in-symfony-4-4-service-container-linter) 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`.

```txt
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 !