Workflow front-end : un nouvel espoir (partie 1)

Cet article est issu d'une réflexion postée à l'origine sur notre Discourse en novembre 2017.

Présentant l'état de notre workflow actuel, il est le premier d'une série consacrée à sa refonte, ainsi qu'à celle de nos outils et pratiques front-end.

TL;DR : trop d'outils sont dépassés / démultipliés, on devrait tout jeter et passer à Webpack — Entre Webpack et Webpack Encore, Webpack paraît plus complet — Go npm — Rester sur Trowel c’est risqué — Si on pouvait mettre en place des tests front, ça serait mieux.

Suite à une réflexion personnelle et en discutant avec quelques membres de la team back et d’autres dev de mon entourage, j’en suis arrivée à cette conclusion : on ne peut plus continuer avec notre workflow front actuel. Encore récemment, j’ai eu une démonstration qu’on allait finir par aller droit dans le mur en continuant avec la stack front actuelle :

Un message qui rassure

Que dit ce message ? Que d’un moment à un autre, n’importe quelle partie du front pourrait tomber en morceaux à cause de Ouvre une nouvelle fenêtreBower (un outil en ligne de commande permettant de gérer les dépendances front-end, comme jQuery ou Bootstrap par exemple). Et ça sur tous nos projets qui utilisent Bower (c’est-à-dire tous).

Personnellement et professionnellement, je ne pouvais pas concevoir de continuer ainsi si on voulait livrer du code maintenable, scalable, performant, de qualité et surtout, qui nous apporte de la fierté et la satisfaction d'un travail bien fait.

En parallèle, il arrivait que certains développeurs back viennent me poser les questions suivantes :

• comment compiler les changements de style ?
• comment compiler le js ?
• pourquoi < insérer techno front ici> ne marche plus ?
• je fais quoi pour installer < insérer techno ou feature front ici> ?

En bref, la stack front n’était pas du tout accessible/compréhensible.

Il apparaissait donc que nous devions changer nos outils, notre documentation et nos conventions, non seulement pour produire du code de qualité mais aussi d’un point de vue expérience développeur, pour comprendre et apprécier (ou plutôt, ne pas détester) de travailler côté front.

Mais le Ouvre une nouvelle fenêtremonde magique du front-end a son côté obscur : il bouge sans arrêt. Si bien que tous les jours une nouvelle lib ou un nouvel outil sort en se présentant comme le one tool to rule them all et une lib populaire aujourd’hui (coucou Angular !) Ouvre une nouvelle fenêtrepeut devenir désuète demain (au revoir Angular !).

Nos besoins pour la stack front-end

Vers quels outils se tourner alors ? Comment éviter de se retrouver à nouveau dans le piège dans lequel nous sommes tombés ? Pour répondre à ces questions, on se doit d’étudier celles-qui suivent :

• à quels besoins techniques la stack doit répondre ?
• quelle expérience développeur doit-elle offrir ? (besoins humains)
• de quoi est composée notre stack front aujourd’hui et répond-elle aux exigences précédentes ?

Allons y point par point donc.

La stack front doit répondre aux besoins techniques suivants :

• installer des dépendances et les versionner
• effectuer des tâches liées au développement, principalement la compilation du style, « l’injection » du style et du JS dans la page et la création des sourcemaps. Ces tâches doivent être exécutables via un script ou une commande.
• effectuer des tâches liées à la production : minification, ajout de préfixes etc. Ces tâches doivent être exécutables via un script ou une commande.
• répondre aux exigences d'UX/UI/référencement d'aujourd'hui: rapidité, fluidité, animation, transition, SEO, accessibilité...

Elle doit aussi répondre aux besoins humains suivants :

• être utilisable d’un environnement à un autre (pas seulement sur tous les OS, mais aussi dans un outil comme Docker en ayant des images de base pour nos projets front )
• être aussi light que possible, en environnement de dev et de prod
• être aussi compréhensible et appréhendable que possible par n’importe quel dev (front, inté, back, junior, intermédiaire, senior)

Notre stack actuelle et ses limites

Voyons voir la stack actuelle :

• installation de dépendances et versioning : Bower (pas de versioning), Ouvre une nouvelle fenêtreyarn, Ouvre une nouvelle fenêtrenpm, Ouvre une nouvelle fenêtrecomposer (pour Ouvre une nouvelle fenêtreAssetic)
• tâches en environnement de dev : Ouvre une nouvelle fenêtreGulp, Ouvre une nouvelle fenêtreBabel (transpiler l’ES6+ en ES5), Ouvre une nouvelle fenêtreSass, Ouvre une nouvelle fenêtrePostcss, Ouvre une nouvelle fenêtreTrowel (un framework de framework SCSS créé et maintenu par un ancien développeur front ayant quitté l'équipe), Ouvre une nouvelle fenêtreBootstrap sur la plupart des projets, sauf un en version 4), Ouvre une nouvelle fenêtremaba:wepack, Assetic
• tâches en environnement de prod : maba:webpack, Assetic

Voici tous les fichiers de configurations qu’on peut retrouver pour le front :

On dispose de plusieurs outils qui font la même chose, plus ou moins bien, avec leur propre configuration (qui peuvent entrer en conflit) et leur propre CLI : maîtriser le workflow front actuel demande donc des connaissances dans une multitude d’outils. En soit, ce ne serait pas un problème si on disposait d'une documentation détaillée du workflow/guide de best practices à respecter, mais ce n'est pas vraiment le cas.

En fait, c’est comme si la stack front était un énorme pétrolier qui aurait fait naufrage : des tonnes de pétrole se déversent et s’étalent dans l’océan au fur et à mesure du temps.

NB : Le pétrole représente les outils, l’océan représente les projets, les clients sont les gentils dauphins qui nagent dans l’océan/les blobfish) et nous, nous sommes témoins du naufrage et nous devenons responsables si nous ne faisons rien...

On a donc une expérience développeur un peu catastrophique, ce qui entraîne des pertes de temps (« mais comment et où je gère < insérez tâche front ici > ?! ») et des frustrations. Côté technique, on rencontre des conflits (

Notre réflexion pour améliorer notre workflow front-end

Vous l’aurez bien compris donc, on doit changer notre stack. Avec quels outils ? Bien qu’on évoque souvent le terme de Ouvre une nouvelle fenêtreJS fatigue en parlant de front-end, on peut observer une certaine tendance depuis 2015 dans la sphère fullstack JS: yarn/ npm pour le gestion des dépendances, Webpack pour les tâches de dev et de prod avec Babel, et c’est tout.

Dans le merveilleux monde de Symfony, les choses bougent aussi avec l'abandon progressif d'Assetic au profit de Ouvre une nouvelle fenêtreWebpack Encore, ce qui est d'ailleurs recommandé sur doc officielle de Symfony. Si vous connaissez un peu Laravel, Encore est similaire à Laravel Mix.

C’est clairement l’outil à utiliser pour plusieurs raisons :

• très, très large communauté, techno qui a fait ses preuves
• compréhensible et appréhendable par n’importe quel dev
• simplification du workflow : 1 config file to run them all
• mise en place d’un dev-server accessible depuis n’importe quelle autre machine utilisant le même réseau : ça veut dire pouvoir tester plus facilement le cross-platform et le cross-browser sans preprod, donc avoir des retours de la team design plus tôt

Maintenant, Webpack Encore m'apparaît être du "sucre" non nécessaire autour de Webpack (qui n'est pas un outil si difficile que ça à prendre en main), en particulier si l'on a pour objectif de développer une SPA (Single Page Application) où Symfony aura pour rôle de construire l'API à laquelle le front fera appel. Toutefois, je suis preneuse de retour d’expérience avec Encore !

Pour la gestion des dépendances, je serais plutôt d’avis d’utiliser npm, tout simplement parce que maintenant, par défaut, npm crée un

Côté CSS, la structure qu’on utilise actuellement ( Ouvre une nouvelle fenêtrepattern 7-1) est vraiment bien : très compréhensible et maintenable (du moins, je trouve). Maintenant, doit-on continuer d’ utiliser Trowel ou non ? Je pencherais pour la négative, tout simplement parce qu'on ne sait plus vraiment trop quelle tournure ça pourrait prendre ou même si ça va être maintenu à l’avenir.

Par ailleurs, Trowel est adapté à la structure actuelle de nos projets (CSS et JS séparés), mais rien n’indique qu’à l’avenir on ait des composants monofichiers avec le markup, le style et le script dans un seul fichier, étant donné qu’on va être amené à travailler de plus en plus avec des lib comme React ou Vue. En restant sur l’architecture de style actuelle, on pourrait aussi bien envisager de bouger sur un plugin PostCSS pour répondre à la problématique du theming.

Dernier point : il faudrait envisager de mettre en place des tests côté front (structurel, de comportement et de régression visuelle). Je pense que c’est important de monter en compétences là dessus pour produire de la qualité et éviter de casser des trucs et de s'en apercevoir plus tard. Ça ne remplace en rien la vérification humaine bien sûr, ni la vérification cross-browser.

Toutes ces décisions seraient évidemment déjà testées sur des projets internes avant d’être appliquées sur un projet client bien sûr... car je me refuse à avoir Bower dessus et de voir mes team mates s'arracher les cheveux dessus.