Trois pièges du squelette Symfony 8

Une migration Doctrine impossible à générer, un formulaire de connexion qui refuse tout, des feuilles de style servies en HTML. Trois blocages, trois causes qui ne se devinent pas.

Trois blocages rencontrés en montant un projet neuf sur Symfony 8. Aucun n'est documenté à l'endroit où on le cherche, et tous les trois m'ont coûté du temps. Les voici, avec leur cause et leur correctif.

1. La migration Doctrine refuse de se générer

The setSchema() method requires the DBAL Schema::edit() API
which is not available in the current DBAL version.
This feature requires doctrine/dbal ^4.5 or higher.

Message limpide, sauf que doctrine/dbal 4.5 n'existe qu'en version de développement : impossible à installer sur un projet en stabilité stable. On se retrouve avec un outil qui réclame une dépendance qu'on ne peut pas satisfaire.

La cause n'est pas DBAL mais ce qui l'appelle : doctrine/orm 3.6.8 et doctrine/doctrine-bundle 3.3 utilisent cette API. Redescendre en ORM 3.6.7 et bundle 3.2 débloque tout, sans rien perdre.

La leçon dépasse le cas : quand un projet voisin fonctionne, son composer.lock est une source plus fiable que n'importe quelle recherche. J'ai trouvé la combinaison en lisant celui d'une application en production.

2. Le formulaire de connexion refuse tout

Login correct, mot de passe correct, rejet systématique. En regardant le HTML :

<input type="hidden" name="_csrf_token" value="csrf-token">

La valeur du jeton est littéralement la chaîne csrf-token. Ce n'est pas un bogue : c'est le nouveau mécanisme de jetons sans état, où la valeur n'est qu'un marqueur qu'un contrôleur Stimulus doit remplacer côté navigateur.

Conséquence : sans build front, aucun formulaire ne passe, connexion comprise. Sur un projet qui n'a délibérément pas de JavaScript applicatif, c'est un mur. Le retour aux jetons de session tient en trois lignes :

framework:
    csrf_protection:
        stateless_token_ids: []

3. Le CSS est servi en HTML

La page s'affiche sans style, et la feuille demandée renvoie du HTML. Coupable : la façon de lancer le serveur intégré de PHP.

php -S 127.0.0.1:8000 -t public public/index.php

Passer public/index.php comme routeur envoie toutes les requêtes au contrôleur frontal, y compris celles qui visent un fichier existant. Il faut un routeur qui rende la main sur les fichiers réels :

$chemin = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
if ('/' !== $chemin && is_file(__DIR__.'/../public'.$chemin)) {
    return false;
}
require __DIR__.'/../public/index.php';

Un bonus, sur le cache des fichiers statiques

Dans la foulée, j'avais figé la version des assets à v1 pour forcer le rafraîchissement. Mauvaise idée : une valeur en dur ne change jamais, donc le navigateur sert éternellement la même feuille. Une stratégie de version basée sur la date de modification du fichier règle le problème définitivement, sans build ni manifeste.

Les trois pièges ont un point commun : le message d'erreur décrit le symptôme, jamais la cause. C'est normal — mais c'est aussi pourquoi il vaut mieux les avoir déjà rencontrés.