Symfony UX 3.7 : du CSS validé depuis Twig, sans Node.js

Et si une faute de frappe dans une classe CSS devenait enfin une erreur visible ?

Tous les développeurs front ont déjà perdu du temps sur une classe mal orthographiée qui n'applique aucun style, sans le moindre message d'erreur. Avec la version 3.7 de Symfony UX, publiée début novembre 2026, l'équipe Symfony s'attaque à ce problème et fait sortir plusieurs composants de la phase expérimentale. Voici ce qu'il faut retenir, selon Symfony UX 3.7 released.

UX CSS : des classes générées et contrôlées depuis Twig

Le point central de cette version est un nouveau package expérimental, UX CSS. Il transforme des design tokens en CSS atomique, c'est-à-dire en petites classes dont chacune porte une seule déclaration de style.

Le problème de départ est simple. Quand on écrit des classes utilitaires sous forme de chaînes de texte, comme avec Tailwind CSS, rien ne vérifie leur validité. Une coquille donne une classe inconnue, donc aucun style, et personne n'est prévenu.

UX CSS propose une autre approche. Une fonction Twig nommée css() reçoit des propriétés de style et des tokens de design, puis retourne les noms de classes correspondants. L'idée est inspirée de Panda CSS.

L'intérêt principal tient à la validation, appliquée à chaque appel de css() :

• en mode debug, une propriété ou un token mal nommé s'affiche comme une erreur directement sur la page
• en intégration continue, la commande lint:twig détecte le problème
• au déploiement, cache:clear échoue en production si un appel est invalide

Autrement dit, la faute de frappe est attrapée avant que le code n'atteigne les utilisateurs.

Pas de surcoût à l'exécution

Lorsqu'un appel à css() ne contient aucune valeur dynamique, le résultat est calculé à la compilation du template. Le gabarit compilé contient déjà les noms de classes sous forme de simple chaîne de texte, donc rien n'est recalculé lors du rendu de la page.

Autre atout : la génération de la feuille de style se fait côté PHP. Le code lit vos templates et produit un unique fichier CSS, sans Node.js. Pour une équipe qui souhaite alléger sa chaîne de build front, c'est un argument concret. L'intégration fonctionne notamment avec AssetMapper.

Le package reste expérimental. Il convient donc de le tester sur un périmètre limité avant d'envisager une adoption large.

Les autres nouveautés de la version 3.7

La release regroupe plus de 100 pull requests fusionnées depuis la 3.6. Parmi les évolutions notables :

• UX Image accueille deux serveurs d'images auto-hébergés, utiles pour garder la maîtrise du traitement des visuels sans dépendre d'un service tiers
• UX Toolkit quitte le statut expérimental, ce qui signale une API plus stable
• LiveComponent profite de 13 corrections de bugs
• Dropzone reçoit une série de nouvelles fonctionnalités
• les pages qui affichent de nombreux composants se rendent plus rapidement

La sortie de l'expérimental pour le Toolkit est une bonne nouvelle pour les projets qui hésitaient à s'appuyer dessus à cause du risque de changements cassants.

Comment aborder la mise à jour

Une démarche prudente tient en quelques étapes :

• mettre à jour les packages Symfony UX vers la 3.7 sur une branche dédiée
• exécuter votre suite de tests et vérifier les composants LiveComponent existants
• essayer UX CSS sur un seul composant neuf, plutôt que sur un projet entier
• brancher lint:twig dans votre pipeline pour profiter de la validation des appels css()

Ce test à petite échelle permet d'évaluer l'effet sur votre workflow : lisibilité des templates, rapidité du build, qualité des retours d'erreur.

Conclusion

Symfony UX 3.7 apporte surtout une idée intéressante : traiter le style comme du code vérifiable, au même titre que le reste de l'application. Combinée à un build entièrement en PHP, l'approche d'UX CSS mérite un essai sur votre prochain composant. Pour le détail complet des changements, consultez l'annonce officielle : Symfony UX 3.7 released.