Naomi Hauret, 26/01/2018

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

8 minutes de lecture

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 :

Message de Bower signalant qu'il faut abandonner l'outil au risque de voir son site cesser de fonctionner du jour au lendemain
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 Bower (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 monde 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 !) peut devenir désuète demain (au revoir Angular !).

illustration de la sortie d'un nouveau framework Javascript
La Liberté guidant le peuple - Eugène Delacroix
Chaque nouvelle librairie ou framework Javascript à sa sortie - illustration

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 :

  • A 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), yarn, npm, composer (pour Assetic)

  • Tâches en environnement de dev : Gulp, Babel (transpiler l’ES6+ en ES5), Sass, Postcss, Trowel (un framework de framework SCSS créé et maintenu par un ancien développeur front ayant quitté l'équipe), Bootstrap sur la plupart des projets, sauf un en version 4), maba:wepack, Assetic

  • Tâches en environnement de prod : maba:webpack, Assetic

Voici tous les fichiers de configurations qu’on peut retrouver pour le front : bower.json, package.json, package-lock.json, yarn.lock, .babelrc, webpack.config.js, gulpfile.babel.js, composer.lock, composer.json, app/config/config.yml et au moins 1 fichier de template (base.html.twig).

illustration du workflow front-end actuel, une multiplicité d'outils faisant la même chose
Harpies - Johan Pasch
Notre workflow front à l'heure actuelle - illustration

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 (yarn.lock VS package-lock.json), des problèmes de performances (maba:webpack, Assetic) et de maintenance (Bower, Trowel).

illustration de développeurs tentant de survivre au workflow front-end
Le Radeau de la Méduse - Théodore Géricault
Développeurs de l'équipe tentant de comprendre, travailler et (surtout) survivre au workflow front actuel - illustration

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 JS 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 Webpack 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 !

illustration d'un développeur maîtrisant son workflow front-end grâce à l'outil Webpack
Bonaparte franchissant le Grand-Saint-Bernard - Jacques-Louis David
Développeur lambda et son workflow après la mise en place de Webpack - illustration

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 .lock et que ça évite le doublon yarn.lock/package-json.lock si quelqu’un lance un npm install … au lieu d’un yarn add ou yarn install.

Côté CSS, la structure qu’on utilise actuellement (pattern 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.

illustration de la relation parfaite entre un développeur et son workflow front
L'enlèvement de Psyché - William-Adolphe Bouguereau
Relationship Workflow goal - illustration
comments powered by Disqus

Nos derniers articles