Notre outillage front-end en 2025

Nous sommes désormais 3 intégrateurs et intégratrices chez JoliCode. Afin d’harmoniser nos façons de faire, nous avons décidé de créer un projet vide, une sorte de « front-end starter » qui nous permettrait de démarrer une intégration. Il se base sur Symfony, le framework pour lequel nous sommes experts et intègre l’ensemble des outils, librairies et configurations que nous souhaitons utiliser côté front-end.

Voici un tour d’horizon de notre front-end starter et des différents choix que nous avons fait pour optimiser la qualité de nos intégrations.

Gestionnaire de paquets : passage à pnpm

Face à l’engouement autour de pnpm (pour Performant npm), nous nous sommes intéressés à ce gestionnaire de dépendances dont la promesse est d’être beaucoup plus rapide et performant que ses concurrents. Il repose sur le principe de liens symboliques afin de partager les dépendances entre plusieurs projets à un seul endroit. Concrètement, si une même librairie est utilisée sur deux projets différents, celle-ci ne sera stockée qu’à un endroit et le dossier node_modules contiendra un lien symbolique vers cette ressource. On peut enfin se débarrasser de ce dossier toujours plus lourd que l’on se coltine sur chaque projet.

Avec sa version 4, Yarn a rattrapé son retard avec sa stratégie Plug’n’Play. Ayant expérimenté pnpm au préalable, nous avons toutefois décidé de rester sur cet outil. Il a, pour le moment, répondu à nos attentes en nous offrant un confort de développement supplémentaire grâce à sa vitesse.

Maintien des standards avec les linters

L’utilisation de linters nous permet d’assurer une cohérence dans le code de nos projets. Le fait de l’intégrer à notre starter garantit le partage des standards à l’ensemble de ceux-ci. Nous ne faisons pas dans l’originalité à ce niveau-là puisque nous utilisons eslint pour le code JavaScript et stylelint pour le css.

Pas de configuration vraiment particulière pour eslint, nous nous basons sur @eslint/js et utilisons la configuration recommended. Pour stylelint, en plus de la configuration standard, nous nous assurons de respecter un certain ordre pour nos règles CSS en surchargeant quelques règles comme selector-class-pattern pour nous permettre d’utiliser la notation BEM. Dans les deux cas, nous utilisons prettier pour formater plus facilement notre code selon les règles définies.

Les outils côté CSS

La fin de SASS

Comme nous en avions parlé dans un précédent article, nous avons décidé de ne plus utiliser le préprocesseur SASS et de nous baser uniquement sur PostCSS. Agrémenté de plugins, il nous permet de retrouver nos automatismes avec l’utilisation d’un préprocesseur (imbrication, mixins…), en supprimant toutefois un outil de notre stack. Nous avons évidemment ajouté le plugin autoprefixer afin de gérer automatiquement l’ajout de préfixes CSS.

Tailwind

Côté framework, nous n’avons pas échappé à la tendance Tailwind. Nous avons décidé de l’intégrer à nos projets, mais pas n’importe comment. Nous utilisons une approche "hybride" : nous n’avons pas supprimé l’utilisation de feuilles de style, nous créons toujours des composants et des classes sémantiques. Cependant, nous les agrémentons des classes utilitaires de tailwind pour nous simplifier la vie. Concrètement, nous créons une classe .btn pour nos boutons. Mais si nous souhaitons ajouter une marge à un bouton en particulier, nous pouvons le faire simplement avec les classes de tailwind. Jonathan a présenté une conférence à Codeurs en Seine pour expliquer notre approche et comment nous l’implémentons.

Nous utilisons actuellement la version 3 du framework mais la dernière version étant sortie cette semaine, nous prévoyons une mise à niveau très rapidement.

L’écosystème Symfony UX

Stimulus

Symfony UX est un ensemble de librairies permettant d’intégrer des outils JavaScript dans nos applications. L’une des librairies principales de Symfony UX est Stimulus, un framework JavaScript minimaliste. C’est une librairie que j’affectionne particulièrement à titre personnel et que j’ai commencé à utiliser il y a plusieurs années au sein de projets Ruby on rails. Elle permet d’organiser son code JavaScript en controlleurs et fonctionne directement sur du HTML (Twig) existant. Pour nos projets sans React, l’utilisation de Stimulus nous permet donc d’avoir un code propre et organisé malgré tout, mais aussi de gagner du temps.

Nous l’avons agrémenté de Stimulus Use qui permet d’utiliser de nouvelles fonctions de cycle de vie au sein d’un controlleur (comme appear, mouseEnter, ou resize).

Les composants Twig

Au sein de Symfony UX, les Twig Components nous permettent de séparer nos éléments en composants réutilisables. Un composant est constitué le plus souvent d’une classe PHP et d’un template Twig associé (il est également possible de créer des composants anonymes qui ne sont constitués que d’un template). Cela nous permet de créer un template pour chaque élément réutilisable (un bouton, une modale…). Nous avions l’habitude d’utiliser le tag embed sur certains projets pour reproduire ce principe de composants Twig mais cela produisait du code peu lisible.

Pour ajouter de l’interactivité à nos composants, nous avons également choisi d’inclure la librairie Live Components. Elle permet de mettre à jour un composant en Ajax lorsque l’utilisateur interagit avec, le tout sans écrire une ligne de JavaScript. C’est une librairie bien pratique dans le cas de composants interactifs, qu’on doit mettre à jour sans rechargement de page et qui nous fait gagner beaucoup de temps.

Certaines voix au sein de Jolicode s’élèvent pour l’utilisation d’HTMX. Nous avons privilégié pour l’instant l’utilisation des outils officiels recommandés par Symfony mais il n’est pas exclu que nous étudions une autre possibilité. Sur un projet récent les Live Components nous ont semblé en effet un peu difficiles à prendre en main et pas forcément adaptés pour répondre à toutes les situations.

Enfin, pour présenter nos composants nous avons décidé d’intégrer Storybook grâce au bundle de SensioLabs. Nous pouvons ainsi visualiser nos différents composants et leurs variantes facilement et ainsi constituer un design system. Auparavant, le design system était un simple template dans lequel nous ajoutions, à la main, les différents composants d’un site. Storybook nous offre une interface complète pour documenter nos composants front.

Gestion des assets

Pour faire fonctionner tout ce petit monde et gérer nos assets, nous utilisons Webpack intégré dans Webpack Encore. Nous avons expérimenté l’utilisation d’Asset Mapper mais malheureusement, au vu des outils que nous utilisons actuellement, nous ne sommes pas prêts à nous passer d’un bundler. Rien de révolutionnaire concernant sa configuration, nous y ajoutons nos linters, Stimulus, PostCSS et de quoi optimiser nos images.

Côté JavaScript enfin, nous ajoutons la librairie Babel pour s’assurer de la compatibilité de notre code.

Quelques librairies JavaScript utiles

Nous avons décidé de n’inclure que peu de librairies JavaScript par défaut dans notre projet starter. Le nombre de librairies qui se retrouvent sur la quasi-totalité de nos projets étant peu nombreux. Nous avons inclus a11y-dialog, une librairie légère créée par Kitty Giraudel qui permet de créer des modales accessibles. Comme elle ne contient pas de style par défaut, nous avons ajouté une feuille de style toute simple qui gère simplement l’affichage d’une modale avec overlay.

Enfin nous échappons rarement à la présence de sliders sur les sites que nous implémentons. Sur ce point, nous avons choisi d’intégrer la libraire Swiper, l’une des rares à répondre à l’ensemble de nos cas d’usage.

Nos outils en image

• Gestionnaire de dépendances, builder, outils : pnpm, Webpack Encore, eslint, stylelint, prettier.
• Eco-système CSS : PostCSS, autoprefixer, Tailwind
• Eco-système JavaScript : Symfony UX (Stimulus, Stimulus Use, Twig Components, Live Components), Babel
• Librairies JavaScript : a11y-dialog, Swiper

Et pour la suite ?

Ce projet n’est bien sûr pas figé et son utilisation au fil du temps pourrait nous amener à effectuer des ajustements. Nous pourrions challenger l’utilisation des live components et pnpm, ajuster notre configuration PostCSS au cours des avancées de CSS ou bien ajouter un linter Twig.