Comment exploiter les machines : être productif avec les exécuteurs de tâches

Les coureurs de tâches sont les héros (ou les méchants, selon votre point de vue) qui travaillent tranquillement derrière la plupart des applications Web et mobiles. Les exécuteurs de tâches apportent de la valeur grâce à l'automatisation de nombreuses tâches de développement telles que la concaténation de fichiers, la mise en place de serveurs de développement et la compilation de code. Dans cet article, nous aborderons les scripts Grunt, Gulp, Webpack et npm. Nous vous fournirons également quelques exemples de chacun pour vous aider à démarrer. Vers la fin, je vous présenterai quelques gains faciles et des conseils pour intégrer les idées de cet article dans votre application.

Il y a un sentiment que les exécuteurs de tâches, et les avancées de JavaScript en général, compliquent trop le paysage frontal. Je conviens que passer la journée entière à peaufiner les scripts de construction n'est pas toujours la meilleure utilisation de votre temps, mais les exécuteurs de tâches présentent certains avantages lorsqu'ils sont utilisés correctement et avec modération. C'est notre objectif dans cet article, de couvrir rapidement les bases des exécuteurs de tâches les plus populaires et de fournir des exemples solides pour stimuler votre imagination sur la façon dont ces outils peuvent s'intégrer à votre flux de travail.

Lectures complémentaires sur SmashingMag :

• Devenez un utilisateur avancé de la ligne de commande avec Oh-My-ZSH et Z
• Une introduction à PostCSS
• Levez-vous et courez avec Grunt
• Construire avec Gulp

Une note sur la ligne de commande

Les exécuteurs de tâches et les outils de génération sont principalement des outils de ligne de commande. Tout au long de cet article, je supposerai un niveau décent d'expérience et de compétence dans l'utilisation de la ligne de commande. Si vous comprenez comment utiliser des commandes courantes telles que cd , ls , cp et mv , tout devrait bien se passer lorsque nous passons en revue les différents exemples. Si vous ne vous sentez pas à l'aise avec ces commandes, un excellent article d'introduction est disponible sur Smashing Magazine. Commençons avec le grand-père de tous : Grunt.

Grognement

Grunt a été le premier exécuteur de tâches populaire basé sur JavaScript. J'utilise Grunt sous une forme ou une autre depuis 2012. L'idée de base derrière Grunt est que vous utilisez un fichier JavaScript spécial, Gruntfile.js , pour configurer divers plugins afin d'accomplir des tâches. Il possède un vaste écosystème de plugins et est un outil très mature et stable. Grunt a un répertoire Web fantastique qui indexe la majorité des plugins (environ 5 500 actuellement). Le génie simple de Grunt est sa combinaison de JavaScript et l'idée d'un fichier de configuration commun (comme un makefile), qui a permis à de nombreux autres développeurs de contribuer et d'utiliser Grunt dans leurs projets. Cela signifie également que Grunt peut être placé sous le même système de contrôle de version que le reste du projet.

Grunt est stable et testé au combat. Au moment de la rédaction, la version 1.0.0 a été publiée, ce qui est une énorme réussite pour l'équipe Grunt. Étant donné que Grunt configure en grande partie divers plugins pour qu'ils fonctionnent ensemble, il peut s'emmêler (c'est-à-dire désordonné et déroutant à modifier) ​​assez rapidement. Cependant, avec un peu de soin et d'organisation (diviser les tâches en fichiers logiques !), vous pouvez faire des merveilles pour n'importe quel projet.

Dans les rares cas où un plugin n'est pas disponible pour accomplir la tâche dont vous avez besoin, Grunt fournit une documentation sur la façon d'écrire votre propre plugin. Tout ce que vous devez savoir pour créer votre propre plugin est JavaScript et l'API Grunt. Vous n'aurez presque jamais à créer votre propre plugin, alors regardons comment utiliser Grunt avec un plugin assez populaire et utile !

Un exemple

Regardons comment Grunt fonctionne réellement. L'exécution de grunt dans la ligne de commande déclenchera le programme de ligne de commande Grunt qui recherche Gruntfile.js à la racine du répertoire. Le Gruntfile.js contient la configuration qui contrôle ce que Grunt fera. En ce sens, Gruntfile.js peut être vu comme une sorte de livre de cuisine que le cuisinier (c'est-à-dire Grunt, le programme) suit ; et, comme tout bon livre de cuisine, Gruntfile.js contiendra de nombreuses recettes (c'est-à-dire des tâches).

Nous allons mettre Grunt à l'épreuve en utilisant le plugin Grunticon pour générer des icônes pour une application Web hypothétique. Grunticon prend un répertoire de SVG et crache plusieurs actifs :

• un fichier CSS avec les SVG encodés en base 64 comme images d'arrière-plan ;
• un fichier CSS avec les versions PNG des SVG encodés en base 64 comme images d'arrière-plan ;
• un fichier CSS qui fait référence à un fichier PNG individuel pour chaque icône.

Les trois fichiers différents représentent les différentes capacités des navigateurs et des appareils mobiles. Les appareils modernes recevront les SVG haute résolution en une seule requête (c'est-à-dire un seul fichier CSS). Les navigateurs qui ne gèrent pas les fichiers SVG mais qui gèrent les ressources encodées en base 64 obtiendront la feuille de style PNG en base 64. Enfin, tous les navigateurs qui ne peuvent pas gérer ces deux scénarios obtiendront la feuille de style "traditionnelle" qui fait référence aux PNG. Tout cela à partir d'un seul répertoire de SVG !

La configuration de cette tâche ressemble à ceci :

 module.exports = function(grunt) { grunt.config("grunticon", { icons: { files: [ { expand: true, cwd: 'grunticon/source', src: ["*.svg", ".png"], dest: 'dist/grunticon' } ], options: [ { colors: { "blue": "blue" } } ] } }); grunt.loadNpmTasks('grunt-grunticon'); };

Passons en revue les différentes étapes ici :

1. Vous devez avoir Grunt installé globalement.
2. Créez le fichier Gruntfile.js à la racine du projet. Il est préférable d'installer également Grunt en tant que dépendance npm dans votre fichier package.json avec Grunticon via npm i grunt grunt-grunticon --save-dev .
3. Créez un répertoire de SVG et un répertoire de destination (où iront les actifs construits).
4. Placez un petit script dans l'en- head de votre code HTML, qui déterminera les icônes à charger.

Voici à quoi votre répertoire devrait ressembler avant d'exécuter la tâche Grunticon :

 |-- Gruntfile.js |-- grunticon | `-- source | `-- logo.svg `-- package.json
|-- Gruntfile.js |-- grunticon | `-- source | `-- logo.svg `-- package.json

Une fois ces éléments installés et créés, vous pouvez copier l'extrait de code ci-dessus dans Gruntfile.js . Vous devriez alors pouvoir exécuter grunt grunticon à partir de la ligne de commande et voir votre tâche s'exécuter.

L'extrait ci-dessus fait plusieurs choses :

• ajoute un nouvel objet de config à Grunt à la ligne 32 nommé grunticon ;
• remplit les différentes options et paramètres de Grunticon dans l'objet icons ;
• enfin, tire le plugin Grunticon via loadNPMTasks .

Voici à quoi votre répertoire devrait ressembler après Grunticon :

 |-- Gruntfile.js |-- dist | `-- grunticon | |-- grunticon.loader.js | |-- icons.data.png.css | |-- icons.data.svg.css | |-- icons.fallback.css | |-- png | | `-- logo.png | `-- preview.html |-- grunticon | `-- source | `-- logo.svg `-- package.json
|-- Gruntfile.js |-- dist | `-- grunticon | |-- grunticon.loader.js | |-- icons.data.png.css | |-- icons.data.svg.css | |-- icons.fallback.css | |-- png | | `-- logo.png | `-- preview.html |-- grunticon | `-- source | `-- logo.svg `-- package.json

Voilà, c'est fini ! En quelques lignes de configuration et quelques installations de packages, nous avons automatisé la génération de nos ressources d'icônes ! Espérons que cela commence à illustrer la puissance des coureurs de tâches : fiabilité, efficacité et portabilité.

Gulp : des blocs LEGO pour votre système de construction

Gulp est apparu quelque temps après Grunt et aspirait à être un outil de construction qui n'était pas uniquement une configuration mais du code réel. L'idée derrière le code plutôt que la configuration est que le code est beaucoup plus expressif et flexible que la modification de fichiers de configuration sans fin. L'obstacle avec Gulp est qu'il nécessite plus de connaissances techniques que Grunt. Vous devrez être familiarisé avec l'API de streaming Node.js et être à l'aise avec l'écriture de JavaScript de base.

L'utilisation par Gulp des flux Node.js est la principale raison pour laquelle il est plus rapide que Grunt. L'utilisation de flux signifie qu'au lieu d'utiliser le système de fichiers comme "base de données" pour les transformations de fichiers, Gulp utilise des transformations en mémoire. Pour plus d'informations sur les flux, consultez la documentation de l'API de flux Node.js, ainsi que le manuel de flux.

Un exemple

Comme dans la section Grunt, nous allons mettre Gulp à l'épreuve avec un exemple simple : concaténer nos modules JavaScript dans un seul fichier d'application.

Exécuter Gulp est identique à exécuter Grunt. Le programme de ligne de commande gulp recherchera le livre de recettes de recettes (c'est-à-dire Gulpfile.js ) dans le répertoire dans lequel il est exécuté.

Limiter le nombre de requêtes effectuées par chaque page est considéré comme une bonne pratique en matière de performances Web (en particulier sur mobile). Pourtant, la collaboration avec d'autres développeurs est beaucoup plus facile si la fonctionnalité est divisée en plusieurs fichiers. Entrez les coureurs de tâches. Nous pouvons utiliser Gulp pour combiner les multiples fichiers de JavaScript pour notre application afin que les clients mobiles doivent charger un seul fichier, au lieu de plusieurs.

Gulp a le même écosystème massif de plugins que Grunt. Donc, pour faciliter cette tâche, nous allons nous appuyer sur le plugin gulp-concat. Disons que la structure de notre projet ressemble à ceci :

 |-- dist | `-- app.js |-- gulpfile.js |-- package.json `-- src |-- bar.js `-- foo.js

Deux fichiers JavaScript se trouvent dans notre répertoire src et nous souhaitons les combiner en un seul fichier, app.js , dans notre répertoire dist/ . Nous pouvons utiliser la tâche Gulp suivante pour accomplir cela.

 var gulp = require('gulp'); var concat = require('gulp-concat'); gulp.task('default', function() { return gulp.src('./src/*.js') .pipe(concat('app.js')) .pipe(gulp.dest('./dist/')); });

Les bits importants se trouvent dans le rappel gulp.task . Là, nous utilisons l'API gulp.src pour obtenir tous les fichiers qui se terminent par .js dans notre répertoire src . L'API gulp.src renvoie un flux de ces fichiers, que nous pouvons ensuite transmettre (via l'API pipe ) au plugin gulp-concat. Le plugin concatène ensuite tous les fichiers du flux et le transmet à la fonction gulp.dest . La fonction gulp-dest écrit simplement l'entrée qu'elle reçoit sur le disque.

Vous pouvez voir comment Gulp utilise les flux pour nous donner des "blocs de construction" ou des "chaînes" pour nos tâches. Un flux de travail Gulp typique ressemble à ceci :

1. Obtenez tous les fichiers d'un certain type.
2. Transmettez ces fichiers à un plugin (concat !), ou effectuez une transformation.
3. Passez ces fichiers transformés à un autre bloc (dans notre cas, le bloc dest , qui termine notre chaîne).

Comme dans l'exemple Grunt, le simple fait d'exécuter gulp à partir de la racine de notre répertoire de projet déclenchera la tâche default définie dans le fichier Gulpfile.js . Cette tâche concatène nos fichiers et nous permet de développer notre application ou notre site Web.

Webpack

Le dernier ajout au club des coureurs de tâches JavaScript est Webpack. Webpack se présente comme un "module bundler", ce qui signifie qu'il peut créer dynamiquement un ensemble de code JavaScript à partir de plusieurs fichiers distincts à l'aide de modèles de module tels que le modèle CommonJS. Webpack a également des plugins, qu'il appelle des chargeurs.

Webpack est encore assez jeune et possède une documentation assez dense et déroutante. Par conséquent, je recommanderais le référentiel Webpack de Pete Hunt comme un excellent point de départ avant de plonger dans la documentation officielle. Je ne recommanderais pas non plus Webpack si vous débutez avec les coureurs de tâches ou si vous ne vous sentez pas compétent en JavaScript. Ces problèmes mis à part, il s'agit toujours d'un outil plus spécifique que l'étendue générale de Grunt et Gulp. De nombreuses personnes utilisent Webpack aux côtés de Grunt ou Gulp pour cette raison même, laissant Webpack exceller dans le regroupement de modules et laissant Grunt ou Gulp gérer des tâches plus génériques.

Webpack nous permet finalement d'écrire du code de style Node.js pour le navigateur, une grande victoire pour la productivité et une séparation nette des préoccupations dans notre code via des modules. Utilisons Webpack pour obtenir le même résultat qu'avec l'exemple Gulp, en combinant plusieurs fichiers JavaScript dans un seul fichier d'application.

Un exemple

Webpack est souvent utilisé avec Babel pour transpiler le code ES6 vers ES5. Transpiler le code d'ES6 vers ES5 permet aux développeurs d'utiliser la norme ES6 émergente tout en servant ES5 aux navigateurs ou aux environnements qui ne prennent pas encore entièrement en charge ES6. Cependant, dans cet exemple, nous nous concentrerons sur la création d'un simple ensemble de nos deux fichiers à partir de l'exemple Gulp. Pour commencer, nous devons installer Webpack et créer un fichier de configuration, webpack.config.js . Voici à quoi ressemble notre fichier :

 module.exports = { entry: "./src/foo.js", output: { filename: "app.js", path: "./dist" } };

Dans cet exemple, nous pointons Webpack vers notre fichier src/foo.js pour commencer son travail de parcours de notre graphique de dépendance. Nous avons également mis à jour notre fichier foo.js pour qu'il ressemble à ceci :

 //foo.js var bar = require("./bar"); var foo = function() { console.log('foo'); bar(); }; module.exports = foo;

Et nous avons mis à jour notre fichier bar.js pour qu'il ressemble à ceci :

 //bar.js var bar = function() { console.log('bar'); }; module.exports = bar;

Ceci est un exemple CommonJS très basique. Vous remarquerez que ces fichiers « exportent » désormais une fonction. Essentiellement, CommonJS et Webpack nous permettent de commencer à organiser notre code en modules autonomes qui peuvent être importés et exportés dans notre application. Webpack est assez intelligent pour suivre les mots-clés d'importation et d'exportation et pour tout regrouper dans un seul fichier, dist/app.js . Nous n'avons plus besoin de maintenir une tâche de concaténation, et nous devons simplement adhérer à une structure pour notre code à la place. Bien mieux !

Extension

Webpack s'apparente à Gulp en ce sens que « c'est juste du JavaScript ». Il peut être étendu pour effectuer d'autres tâches d'exécution de tâches via son système de chargeur. Par exemple, vous pouvez utiliser css-loader et sass-loader pour compiler Sass en CSS et même utiliser le Sass dans votre JavaScript en surchargeant le modèle require CommonJS ! Cependant, je préconise généralement d'utiliser Webpack uniquement pour créer des modules JavaScript et d'utiliser une autre approche plus générale pour l'exécution des tâches (par exemple, les scripts Webpack et npm ou Webpack et Gulp pour gérer tout le reste).

Scripts npm

Les scripts npm sont le dernier engouement hipster, et pour cause. Comme nous l'avons vu avec tous ces outils, le nombre de dépendances qu'ils pourraient introduire dans un projet pourrait éventuellement devenir incontrôlable. Le premier article que j'ai vu plaidant pour les scripts npm comme point d'entrée d'un processus de construction était celui de James Halliday. Son article résume parfaitement le pouvoir ignoré des scripts npm (c'est moi qui souligne):

Il existe des outils sophistiqués pour l'automatisation de la construction sur des projets JavaScript dont je n'ai jamais ressenti l'attrait, car la commande npm run , moins connue, a été parfaitement adaptée à tout ce que j'avais à faire tout en conservant une très petite empreinte de configuration .

Avez-vous attrapé ce dernier morceau à la fin? Le principal attrait des scripts npm est qu'ils ont une "très petite empreinte de configuration". C'est l'une des principales raisons pour lesquelles les scripts npm ont commencé à faire leur chemin (près de quatre ans plus tard, malheureusement). Avec Grunt, Gulp et même Webpack, on finit par se noyer dans les plugins qui enveloppent les binaires et doublent le nombre de dépendances dans un projet.

Keith Cirkel a le tutoriel incontournable sur l'utilisation de npm pour remplacer Grunt ou Gulp. Il fournit le plan directeur pour tirer pleinement parti de la puissance des scripts npm, et il a introduit un plugin essentiel, Parallel Shell (et une foule d'autres comme lui).

Un exemple

Dans notre section sur Grunt, nous avons pris le module populaire Grunticon et créé des icônes SVG (avec des alternatives PNG) dans une tâche Grunt. C'était le seul point douloureux avec les scripts npm pour moi. Pendant un certain temps, je garderais Grunt installé pour des projets juste pour utiliser Grunticon. Je «débourserais» littéralement à Grunt dans ma tâche npm pour réaliser la création du coureur de tâches (ou, comme nous avons commencé à l'appeler au travail, un outil de construction turducken). Heureusement, The Filament Group, le groupe fantastique derrière Grunticon, a publié une version autonome (c'est-à-dire sans Grunt) de son outil, Grunticon-Lib. Alors, utilisons-le pour créer des icônes avec des scripts npm !

Cet exemple est un peu plus avancé qu'une tâche de script npm typique. Une tâche de script npm typique est un appel à un outil de ligne de commande, avec les indicateurs ou le fichier de configuration appropriés. Voici une tâche plus typique qui compile notre Sass en CSS :

 "sass": "node-sass src/scss/ -o dist/css",

Vous voyez comme il s'agit d'une seule ligne avec diverses options ? Aucun fichier de tâche n'est nécessaire, aucun outil de construction à faire tourner - il suffit d' npm run sass à partir de la ligne de commande, et vous êtes Sass est maintenant CSS. Une fonctionnalité très intéressante des scripts npm est la façon dont vous pouvez enchaîner les tâches de script. Par exemple, supposons que nous voulions exécuter une tâche avant l'exécution de notre tâche Sass. Nous créerions une nouvelle entrée de script comme celle-ci :

 "presass": "echo 'before sass',

C'est vrai : npm comprend le pre- -préfixe. Il comprend également le post- préfixe. Toute entrée de script portant le même nom qu'une autre entrée de script avec un pre- ou un post- préfixe s'exécutera avant ou après cette entrée.

La conversion de nos icônes nécessitera un fichier Node.js réel. Ce n'est pourtant pas trop grave. Créez simplement un répertoire de tasks et créez un nouveau fichier nommé grunticon.js ou icons.js ou tout ce qui a du sens pour ceux qui travaillent sur le projet. Une fois le fichier créé, nous pouvons écrire du JavaScript pour déclencher notre processus Grunticon.

Remarque : Tous ces exemples utilisent ES6, nous allons donc utiliser babel-node pour exécuter notre tâche. Vous pouvez facilement utiliser ES5 et Node.js, si c'est plus confortable.

 import icons from "grunticon-lib"; import globby from "globby"; let files = globby.sync('src/icons/*'); let options = { colors: { "blue": "blue" } }; let icon = new icons(files, 'dist/icons', options); icon.process();

Entrons dans le code et découvrons ce qui se passe.

1. Nous import (c'est-à-dire exigeons) deux bibliothèques, grunticon-lib et globby . Globby est l'un de mes outils préférés, et il facilite le travail avec les fichiers et les globs. Globby améliore Node.js Glob (sélectionnez tous les fichiers JavaScript via ./*.js ) avec la prise en charge de Promise. Dans ce cas, nous l'utilisons pour obtenir tous les fichiers du répertoire src/icons .
2. Une fois que nous avons fait cela, nous définissons quelques options dans un objet options puis appelons Grunticon-Lib avec trois arguments :
   • les fichiers d'icônes,
   • la destination,
   • les options. La bibliothèque prend le relais et mâche ces icônes et crée finalement les versions SVG et PNG dans le répertoire que nous voulons.
3. Nous avons presque terminé. N'oubliez pas qu'il s'agit d'un fichier séparé et que nous devons ajouter un "hook" pour appeler ce fichier à partir de notre script npm, comme ceci : "icons": "babel-node tasks/icons.js" .
4. Maintenant, nous pouvons exécuter npm run icons , et nos icônes seront créées à chaque fois.

Les scripts npm offrent un niveau de puissance et de flexibilité similaire à celui des autres exécuteurs de tâches, sans la dette du plugin.

Répartition des coureurs de tâches couverts ici

Quelques victoires faciles

Tous ces exemples et exécuteurs de tâches peuvent sembler écrasants, alors décomposons-les. Tout d'abord, j'espère que vous ne retiendrez pas de cet article que le gestionnaire de tâches ou le système de construction que vous utilisez actuellement doit être instantanément remplacé par celui mentionné ici. Le remplacement de systèmes importants comme celui-ci ne doit pas se faire sans beaucoup de considération. Voici mon conseil pour mettre à niveau un système existant : Faites-le progressivement.

Scripts d'emballage !

Une approche incrémentielle consiste à envisager d'écrire quelques scripts npm "wrapper" autour de vos exécuteurs de tâches existants afin de fournir un vocabulaire commun pour les étapes de construction qui est en dehors de l'exécuteur de tâches réel utilisé. Un script wrapper pourrait être aussi simple que ceci :

 { "scripts": { "start": "gulp" } }

De nombreux projets utilisent les blocs de script start et test npm pour aider les nouveaux développeurs à s'acclimater rapidement. Un script wrapper introduit une autre couche d'abstraction dans la chaîne de construction de votre coureur de tâches, mais je pense qu'il vaut la peine de pouvoir standardiser autour des primitives npm (par exemple test ). Les commandes npm ont une meilleure longévité qu'un outil individuel.

Saupoudrer dans un petit Webpack

Si vous ou votre équipe ressentez la douleur de maintenir un "ordre de bundle" fragile pour votre JavaScript, ou si vous cherchez à passer à ES6, considérez cela comme une opportunité d'introduire Webpack dans votre système d'exécution de tâches existant. Webpack est génial dans la mesure où vous pouvez en utiliser autant ou aussi peu que vous le souhaitez tout en en tirant de la valeur. Commencez simplement par regrouper votre code d'application, puis ajoutez babel-loader au mélange. Webpack a une telle profondeur de fonctionnalités qu'il pourra accueillir à peu près tous les ajouts ou nouvelles fonctionnalités pendant un certain temps.

Utilisez facilement PostCSS avec les scripts npm

PostCSS est une excellente collection de plugins qui transforment et améliorent le CSS une fois qu'il est écrit et prétraité. En d'autres termes, c'est un post-processeur. Il est assez facile d'exploiter PostCSS à l'aide de scripts npm. Supposons que nous ayons un script Sass comme dans notre exemple précédent :

 "sass": "node-sass src/scss/ -o dist/css",

Nous pouvons utiliser les mots clés du lifecycle de vie du script npm pour ajouter un script à exécuter automatiquement après la tâche Sass :

 "postsass": "postcss --use autoprefixer -c postcss.config.json dist/css/*.css -d dist/css",

Ce script s'exécutera à chaque exécution du script Sass. Le package postcss-cli est génial, car vous pouvez spécifier la configuration dans un fichier séparé. Notez que dans cet exemple, nous ajoutons une autre entrée de script pour accomplir une nouvelle tâche ; il s'agit d'un modèle courant lors de l'utilisation de scripts npm. Vous pouvez créer un flux de travail qui accomplit toutes les différentes tâches dont votre application a besoin.

Conclusion

Les coureurs de tâches peuvent résoudre de vrais problèmes. J'ai utilisé des exécuteurs de tâches pour compiler différentes versions d'une application JavaScript, selon que la cible était la production ou le développement local. J'ai également utilisé des exécuteurs de tâches pour compiler des modèles de guidon, pour déployer un site Web en production et pour ajouter automatiquement des préfixes de fournisseur qui manquent dans mon Sass. Ce ne sont pas des tâches triviales, mais une fois qu'elles sont intégrées dans un gestionnaire de tâches, elles deviennent sans effort.

Les coureurs de tâches évoluent et changent constamment. J'ai essayé de couvrir les plus utilisés dans l'air du temps actuel. Cependant, il y en a d'autres que je n'ai même pas mentionnés, comme le brocoli, le brunch et la harpe. N'oubliez pas que ce ne sont que des outils : utilisez-les uniquement s'ils résolvent un problème particulier, et non parce que tout le monde les utilise. Bonne tâche en cours d'exécution !