Back in issue 87, I introduced readers to Node.JS and the task runner “Grunt”. I recently discovered an alternative called Gulp, which appeals to me a bit better (more on that soon). Around the same time, a reader asked if I could cover Gulp in C&C. So here it is. What’s the difference? The difference between Gulp and Grunt is mainly in their approach to the running of tasks. Grunt focuses on a configuration-based system where you define each task’s configurations (files, compression, plugin to use, etc). Whereas Gulp focuses on a streaming workflow - that means one plugin for one task (no overlap), and is more programmatic than configuration-based. This means the Gulp tasks look more like a JavaScript function that uses a series of callback functions with each configuration step. It may be easier to see the difference by simply covering how Gulp works. If you want a presentation on the differences, see the further reading section. Example repository The repository can be found on GitHub here: https://github.com/lswest/FCM93-Gulp-Example Gulpfile.js This is the file that creates and organizes the tasks Gulp is supposed to run. The first 7 lines of the file (the var name = require(‘name’);) simply initialize the various Node.JS packages you need. These need to have been installed with npm first – if you have your package.json file, simply running npm install will be sufficient. The reason why you place the extensions into variables is to make calling them easier, and the reason they’re required is to enable the usage of npm packages like Stylus from within gulp. In the example file, I then create two tasks. The ‘app’ task starts on line 9 and runs to line 21. The ‘uglify’ task is on lines 23-28. The names of the tasks are arbitrary.
Dans le numéro 87, je vous ai présenté Node.JS et le lanceur de tâches « Grunt ». J'ai récemment découvert une alternative appelée Gulp, qui m'attire un peu plus (je vous en donnerai les raisons bientôt). Vers la même époque, un lecteur m'a demandé si je pouvais parler de Gulp dans C&C. Alors voilà.
Quelle est la différence ?
La différence entre Gulp et Grunt est principalement dans leur approche de la gestion des tâches. Grunt se concentre sur un système basé sur la configuration où vous définissez les configurations de chaque tâche (fichiers, compression, greffon à utiliser, etc.). Alors que Gulp se concentre sur un flux de travail continu : cela signifie un greffon par tâche (pas de chevauchement) et relève plus de la programmation que de la configuration. Cela signifie que les tâches Gulp ressemblent plus à une fonction JavaScript qui utilise une série de fonctions de rappel à chaque étape de configuration. Il peut être plus facile d'appréhender la différence si je décris le fonctionnement de Gulp. Si vous souhaitez une présentation sur les différences, consultez la section « pour aller plus loin ».
Référentiel d'exemple
Le référentiel peut être trouvé sur GitHub : https://github.com/lswest/FCM93-Gulp-Example.
Gulpfile.js
C'est le fichier qui crée et organise les tâches que Gulp est censé lancer. Les sept premières lignes du fichier (la var name = require(‘name’);) initialisent tout simplement les différents paquets Node.js dont vous avez besoin. Celles-ci doivent avoir été installées auparavant avec npm : si vous avez le fichier package.json, l'exécution de npm install sera suffisant.
La raison pour laquelle vous placez les extensions dans des variables est de rendre plus facile leur appel, et la raison pour laquelle elles sont obligatoires est de permettre l'utilisation de paquets de npm comme Stylus à partir de Gulp.
Dans le fichier d'exemple, je crée alors deux tâches. La tâche 'app' commence sur la ligne 9 et va jusqu'à la ligne 21. La tâche « uglify » (enlaidir) est sur les lignes 23-28. Le nom des tâches est à votre libre choix.
The app Task This task is intended to compile preprocessor CSS files into CSS - I use it for stylus, but the same idea applies to SASS and Less (so long as you have the correct packages installed). The task starts with first running gulp.src - which tells it where to find the stylus file(s). It should be possible to concatenate or use an *.styl call to open all stylus files. As, however, the best practice is to reduce the number of css files a site has to call, using only one stylus file to compile is best. Use the @import function to include other stylus files, so that there is only one resulting CSS file. Afterwards, there’s a pipe function called on the .src, where the stylus function is called with a small list of settings. The setting use tells it what stylus plugins to call (in my case, I am using only Jeet for the Jeet Framework). Compress, as you might imagine, controls the setting for compressing files (minifying the CSS). The sourcemap array controls a few settings for creating a source map file as well, so that the browser inspector gives you line numbers relevant to the original stylus file, as opposed to referencing the minified CSS file. This is useful for developing, but can be left out if you’d prefer. Last but not least, .pipe(gulp.dest('./css/')); sets the destination folder for the created files. Hopefully by now the term “stream-based” is making more sense. Each function call has one purpose, and it’s strung together one step at a time (into a stream), until you have your final result.
La tâche « app »
Cette tâche est censée compiler des fichiers préprocesseur CSS en CSS : je l'utilise pour stylus, mais la même idée s'applique à SASS et Less (si vous avez les bons paquets installés).
La tâche commence par lancer d'abord gulp.src, qui lui indique où trouver le(s) fichier(s) de stylus. Il devrait être possible de concaténer ou d'utiliser une expression *.styl pour ouvrir tous les fichiers stylus. Comme, cependant, la meilleure pratique consiste à réduire le nombre de fichiers css qu'un site doit appeler, c'est mieux d'utiliser un seul fichier stylus pour compiler. Utilisez la fonction @import pour inclure d'autres fichiers stylus, de sorte qu'il n'y ait qu'un seul fichier CSS résultant.
Ensuite, il y a une fonction de mise en chaîne appelée sur le .src, où la fonction stylus est appelée avec une petite liste de paramètres. L'utilisation des paramètres indique quels greffons stylus appeler (dans mon cas, j'utilise seulement Jeet pour le Framework Jeet). Compress, comme vous pouvez l'imaginer, contrôle le réglage de la compression des fichiers (rapetissant le CSS). Le tableau sourcemap contrôle quelques paramètres pour créer aussi un fichier de cartographie des sources, afin que l'inspecteur du navigateur vous donne les numéros de ligne correspondant au fichier d'origine de stylus, par opposition à référencer le fichier CSS miniaturisé. C'est utile pour le développement, mais peut être laissé de côté si vous préférez.
Enfin, pour finir en beauté, .pipe(gulp.dest('./css/')); définit le dossier de destination pour les fichiers créés.
Espérons maintenant que le terme « à base de flux » fait un peu plus de sens. Chaque appel de fonction a un but, et elle est mise en file une étape à la fois (dans un flux), jusqu'à ce que vous ayez votre résultat final.
The ‘Uglify’ Task The idea behind this task is to concatenate all JavaScript files, and then minify the result. This makes it much less human-readable, but reduces the file size and the number of external files a website has to use. Hence the term “uglify”. This task begins again with a gulp.src function call (that selects all js files in the folder “js”). After that, it calls three pipe functions. The first one concatenates (combines) all the js files, then runs the uglify function (minifying the resulting merged javascript). The last step, as always, is a dest function call, defining the destination of the resulting file. The Last Line When defining the tasks we need, the last line creates one last task, that I’ve called ‘default’ which runs both of the other functions when called. This way, instead of calling the tasks separately, it actually completes the entire process in one fell swoop. The task is called ‘default’ because that’s the automatic function called by gulp. The end result will be two new files - one minified CSS file, and one minified javascript file. Include these in your HTML head area, and you’re all set. I hope that this article has helped make Gulp look appealing to anyone who was daunted by Grunt in the past. There are various articles on how to use gulp for other typical tasks (such as using it for SASS). As the syntax is (in my opinion) easier to read than Grunt, if you have any experience with JavaScript, it should prove easier to use for beginners. There are some who find task runners to be overly bloated for what it should do. However, the ease-of-use for some cases (especially for those starting out) should outweigh the trade-offs. For those wanting to use npm and reduce bloat, you can simply install the raw packages (such as stylus). To automate things, you can also create a make file or a script to execute the commands. I leave that as an exercise to the user. If you’re using a web framework, they generally have ways of executing function calls themselves. If anyone has any questions, suggestions, or requests, feel free to email me at lswest34+fcm@gmail.com. Further Reading http://markdalgleish.github.io/presentation-build-wars-gulp-vs-grunt/ - Presentation on the differences between Gulp and Grunt. Gulp website: http://gulpjs.com/
La tâche « uglify »
L'idée derrière cette tâche est de concaténer tous les fichiers JavaScript, puis rapetisser le résultat. Cela les rend beaucoup moins lisibles pour un être humain, mais réduit la taille du fichier et le nombre de fichiers externes qu'un site Web doit utiliser. D'où le terme « enlaidir ».
Cette tâche commence aussi avec un appel de fonction à gulp.src (qui sélectionne tous les fichiers js dans le dossier « js »).
Après cela, elle appelle trois fonctions en chaîne. La première concatène (combine) tous les fichiers js, puis lance la fonction uglify (rapetissant le javascript fusionné résultant). La dernière étape, comme toujours, est un appel de fonction dest, pour définir la destination du fichier résultant.
La dernière ligne
Lors de la définition des tâches dont nous avons besoin, la dernière ligne crée une dernière tâche, que j'ai appelé « default » qui lance les deux autres fonctions lorsqu'elle est appelée. De cette façon, au lieu d'appeler les tâches séparément, elle remplit effectivement l'ensemble du processus d'un seul coup. La tâche est appelée « default » parce que c'est la fonction automatique appelé par Gulp.
Le résultat final sera deux nouveaux fichiers : un fichier CSS miniaturisé, et un fichier javascript miniaturisé. Incluez-les dans votre en-tête HTML, et tout est prêt.
J'espère que cet article a contribué à rendre attirant Gulp pour toute personne qui a été intimidée par Grunt dans le passé. Il y a divers articles sur la façon d'utiliser Gulp pour d'autres tâches typiques (telles que l'utiliser pour SASS). Comme la syntaxe est (à mon avis) plus facile à lire que Grunt, si vous avez une expérience avec JavaScript, ça devrait s'avérer plus facile à utiliser pour les débutants. Certains pensent que les lanceurs de tâches sont trop ballonnés pour ce qu'ils doivent faire. Mais, la facilité d'utilisation pour certains cas (surtout pour ceux qui débutent) devrait l'emporter sur les compromis. Pour ceux qui veulent utiliser npm et réduire le ballonnement, vous pouvez simplement installer les paquets de base (comme stylus). Pour automatiser les choses, vous pouvez aussi créer un fichier make ou un script pour exécuter les commandes. Je laisse cela comme un exercice aux utilisateurs. Si vous utilisez un framework Web, ils ont eux-mêmes généralement des moyens d'exécuter des appels de fonction.
Si quelqu'un a des questions, des suggestions, ou des demandes, n'hésitez pas à m'envoyer un e-mail à lswest34+fcm@gmail.com.
Pour aller plus loin
http://markdalgleish.github.io/presentation-build-wars-gulp-vs-grunt/ - Présentation des différences entre Gulp et Grunt.
site Web de Gulp : http://gulpjs.com/