Appuyez sur Entrée pour voir vos résultats ou Echap pour annuler.

Commander JS pour vos scripts de développement

Personnellement, je suis un fan de tout ce qui est scripting de tâches répétitives. Parait que c’est une qualité chez un programmeur, la paresse. Je te donne un exemple…

Un client chez qui j’étais utilisait SharePoint pour faire le suivi des demandes à l’équipe de support (juge pas!). Parallèlement à SharePoint, l’équipe de développement gardait une copie de l’information dans VSTS (juge pas!). Une véritable plaie à garder à jour, en plus du tableau Kanban physique. J’ai donc pris 1 heure de mon temps pour me faire une façade en invite de commande pour mettre à jour les demandes dans les deux systèmes en même temps.

C’est compliqué à faire? Pas du tout! On va voir ça ensemble avec commander.

À quoi ça sert?

Commander est une librairie pour Node qui permet de créer facilement des applications en invite de commande en prenant en charge, entre autre, l’analyse des paramètres, la génération automatique de l’aide, le support multi commande et plus. À l’heure d’écrire ceci, cette librairie est à ~31 500 000 téléchargements par semaine sur npm.

Pour débuter, vous devez simplement avoir node installé et partir dans un répertoire vide.

Créer une commande

Le principe derrière commander, c’est qu’on crée des commandes avec des paramètres ou options. L’application analyse la commande utilisée pour lancer le script et exécute du code pour nous. Un exemple vaut 1000 mots, donc créer un fichier dev-tools.js :

Donc ici, on a créé une commande qui est représentée par le fichier source. Puis, à cette commande, on a ajouté une option de débogage. Pour tester, lancer le script comme ceci :

Vous devriez voir quelque chose comme :

On voit aussi que la version de la commande a été prise directement du package.json, ce qui est convivial pour ne pas répéter l’information. Par contre, il se pourrait qu’un même projet consiste en plusieurs commandes. Vous pourriez vouloir versionner chacune des commandes de façon indépendante. Bref…

Si vous exécuter :

Il ne se passe rien, puisque le paramètre -d a été omis. D’ailleurs, si vous remarquez comment l’option a été déclarée :

Vous pouvez voir qu’il y a aussi une version longue du paramètre. On les sépare par une virgule :

Le dernier paramètre sert de documentation. Vous pouvez l’essayer en roulant :

Accepter des valeurs aux paramètres

Supposons qu’on voudrait fournir des données à notre script, comme un fichier d’entrée. Ceci se fait en fournissant une genre de balise xml à la fonction option().

En utilisant les signes < et > dans la définition de l’option, ça en fait un argument obligatoire. Par contre, --in n’est pas obligatoire. path l’est, si --in  est passé en argument. Pour que path devienne optionnel, il faut utiliser [ et ] pour le déclarer.

Pour que l’option comme telle soit obligatoire, il faut simplement utiliser la fonction requiredOption() au lieu de option().

On se retrouve donc à devoir exécuter le script de cette façon, en passant -b et -c avec une valeur.

Conclusion

Aujourd’hui, vous avez appris à utiliser une librairie pour faciliter le développement d’applications en ligne de commande. Personnellement, j’ai des dizaines de scripts comme ça sur mon poste. En bonus, vous pouvez créer un répertoire local et ajouter ce chemin à votre variable d’environnement PATH pour pouvoir exécuter vos scripts de n’importe où sur votre poste. Pensez-y :

Votre script met à jour votre tâche Jira. Ou encore :

Votre script retourne votre prochaine tâche.

Les possibilités sont infinies. Si vous en avez aussi, je veux le savoir dans les commentaires! Merci de partager dans vos réseaux 🙂 Chaque vue est une petite tape dans le dos.

Suivez-nous par courriel!

Saisissez votre adresse courriel pour vous abonner au blog d'Ezo et recevoir une notification de chaque nouvel article par email.

Rejoignez 19 autres abonnés