Au début de l’année 2014 (pfiou, ça fait déjà 3mois), j’ai essayé Gulp, un concurent de Grunt, qui fonctionnait sur un principe différent, axé sur la manipulation de fichiers en tant que streams, accélérant énormément les opérations sur ces fichiers.

À l’époque, sur le papier, c’était tentant, mais malheureusement, le manque de plugin (et l’absence complète de temps pour en écrire de mon côté), m’ont fait rester sur Grunt, en laissant tout de même une note dans mon cahier : essayer gulp dans quelques semaines, le temps de laisser la communauté écrire quelques plugins intéressants.

Et par la force des choses, j’en suis venu à devoir regarder Gulp de plus près, et ce bien plus vite que je ne le pensais.

En effet, dans le cadre d’un gros projet pro qui fera en temps et en heures l’objet d’un ou plusieurs billets, je travaillais avec le workflow suivant :

• Code en Literate CoffeeScript, Stylus et Jade
• Données stockées via MongoDB et Redis
• Tâches de travail via Grunt
• Serveur de test sur une Vagrant avec nodemon

Le workflow n’a pas été mis en place tel quel dès le début, il s’est construit au fur et à mesure du développement du projet, mais après deux mois de travail, en octobre 2013, j’étais sur ce workflow et c’était vraiment un plaisir.
En effet, quand je devais commencer à bosser sur le projet, je naviguais dans le dossier du repo depuis mon Terminal, je rentrais la commande vagrant up && vagrant ssh, puis une fois tout le système déployé, je n’avais plus qu’à taper grunt work pour commencer à bosser.
Jamais besoin de m’inquièter, juste à coder.

Mais un jour de février, le drame. Sur base régulière mais aléatoire, les tâches de watch et nodemon plantaient, devaient être relancées à la main, et ça perturbait énormément mon travail de développement : impossibilité de travailler car des compilations se lançaient au milieux de requêtes de test sur le serveur, fichiers compilés corrompus car réécrits en cours de compilation, bref, un bel enfer, et pas moyen de bosser.

Et ça me fait mal de le dire, mais à ce jour, je ne sais toujours pas ce qu’il s’est passé.

J’ai bien ma petite idée : une dépendance d’une tâche Grunt qui auraient été mise à jour et aurait générer des bugs, mais rien dans la console, rien dans les logs, rien sur github, aucun moyen d’identifier clairement la source du problème.

Dans ce cas-là, on a pas le choix, il faut rebondir (surtout que ça arrivait un jeudi soir, et qu’on avait convenu avec le client de mettre en ligne une nouvelle version de travail chaque fin de semaine) : il me restait pas mal de boulot à terminer, et vite, et je ne me vois pas dire à mon client “mes outils m’ont lâchés”.

Du coup, j’ai passé une nuit blanche à la fois instructive et stressante, où j’ai migré une partie de mon workflow sur Gulp, en serrant les fesses et en espérant que ça marche.
Un p’tit coup de spoiler : ça a marché.

Gulp, il faut dire ce qui est, c’est vraiment terrible. Puissant, rapide, simple à mettre en place… mais aussi très gourmand. Très, très gourmand.

Ça a été un des premiers problèmes rencontré : mon workflow avec Grunt était assez comple(t|xe) : tous les fichiers jade, litcoffee et stylus étaient observés, et à chaque changement, compilés, et le serveur relancé grâce à nodemon.
Un process assez lourd, mais qui fonctionnait très bien jusque là, quoi qu’un peu lent, mais on y reviendra.

Quand j’ai eu fini de retranscrire la base de ce workflow avec Gulp, les résultats en local sur le mac étaient hallucinant : à chaque modification sur un fichier, Gulp compilait le tout en généralement moins d’un quart de secondes, là où Grunt avait souvent besoin d’un peu plus d’une seconde pour faire la même chose.
Seulement, quand Gulp tournait sur la VagrantBox, il prennait un bon gros 5 secondes, parfois plus (beaucoup plus !) pour le même résultat, avec en plus des pics CPU assez important, allant parfois jusqu’à faire planter la Vagrant.

Du coup, j’ai dû changer mon fusil d’épaule : laisser nodemon seul tourner sur la VagrantBox, et lancer le workflow Gulp en local, sur mon mac.
Et là, c’était déjà vachement plus mieux, mais pas encore top.

Cette fois-ci, c’était la faute à nodemon.

Nodemon est un package npm qui lance un script node et le monitore (néologisme, bonsoir) : il observe un ou plusieurs dossiers, et si les fichiers changent, il relance le code.
Pratique, donc.

Mais depuis quelques semaines et la sortie de la version 1.0 de nodemon, je le trouve de plus en plus lent : lent à repérer les changements dans les fichiers, lent à redémarrer le script, et parfois aussi carrément dans les choux, déclarant voir des modifications quand il n’y en a pas.
Bref, plus du tout fiable.
Et c’est bien embêtant dans le cadre d’un outil aussi important dans mon workflow.

Le problème, c’est que de mon côté, je n’avais pas le temps d’investiguer le code de nodemon, d’attendre les réponses de ses créateurs, espérer qu’elles soient rapides, etc…
Il me fallait une solution, et vite.

Du coup, je suis tombé sur supervisor.
Créé et maintenu à l’origine pas le créateur de npm, supervisor fait la même chose que nodemon.
Après quelques tests, il s’avérait aussi qu’il le faisait de manière beaucoup plus rapide.

Le hic, c’est que supervisor n’avait aucun plugin pour grunt ou gulp.
Ce n’était pas vraiment un obstacle en soit, et d’ailleurs je n’avais pas le temps dans l’immédiat (ce qui par la suite a été vite corrigé, puisque j’ai codé et publié grunt-supervisor et gulp-supervisor)

Une fois supervisor installé à la place de nodemon, j’avais enfin un workflow opérationnel, au prix d’une nuit blanche et d’une grosse angoisse.

Et il s’avère au final que ce workflow est bien plus performant que l’ancien, donc…