Créer un outil en ligne de commande

Ce dont nous avons besoin pour démarrer, c’est d’un script Node que nous pouvons appeler depuis notre terminal. Nous allons placer l’exemple suivant dans le répertoire bin (pour binary en anglais, c’est-à-dire exécutable). Cela n’a pas d’incidence technique, mais c’est une pratique courante au sein de la communauté Node pour repérer plus facilement les exécutables sans ambiguïté.

L’exécution du script avec Node retourne la date et l’heure courante – selon l’horloge de l’ordinateur qui exécute le code.

Les systèmes d’exploitation modernes distinguent les fichiers ordinaires des fichiers exécutables. L’appel à un fichier exécutable se fait sans avoir à connaître quoi que ce soit d’autre que son emplacement.

Essayons d’exécuter le script précédent pour nous en rendre compte. Pour ce faire, nous allons l’invoquer seulement avec son chemin – ici, son chemin relatif :

Le système refuse de l’exécuter car les permissions du fichier ne sont pas adéquates. Comme nous ne les connaissons pas, utilisons la commande ls ainsi que l’option -l pour afficher ses informations détaillées :

Cet affichage détaille les permissions du fichier, l’utilisateur et le groupe propriétaire, son poids et enfin la date de dernière modification.

Nous allons rendre le fichier exécutable (+x) pour notre utilisateur (u) grâce à la commande chmod. Je préfère utiliser cette notation car elle évite des effets de bord :

L’utilisation renouvelée de la commande ls confirme que la permission exécutable du fichier a été attribuée à l’utilisateur propriétaire du fichier :

Nous sommes accueillis avec un nouveau message d’erreur lorsque nous tentons d’exécuter le fichier bin/time.js :

La bonne nouvelle, c’est que le fichier est exécutable. Néanmoins, il semblerait que le système d’exploitation ait du mal à l’interpréter.

Donner les permissions d’exécution à un fichier ne suffit donc pas. Nous avons perdu un élément contextuel en supprimant l’appel à node dans l’exécution du script.

Le caractère ++ placé en début de ligne d’un script système signale une ligne placée en commentaire. C’est l’équivalent de +//+ en ECMAScript. Il existe un cas spécial : lorsque le caractère ++ est suivi d’un ! et lorsqu’il s’agit de la première ligne d’un fichier. Le contenu du commentaire est alors utilisé par le système d’exploitation pour déterminer quel programme utiliser pour interpréter le script. C’est ce qu’on appelle shebang.

Modifions le script de la section précédente pour ajouter le shebang :

Le programme /usr/bin/env crée un nouvel environnement d’exécution et le reste du script est passé au programme référencé en argument – ici, node. Ce nouvel environnement dure le temps de l’exécution du script.

Le dernier effort à faire pour distribuer ce script exécutable de manière interopérable est de le lier à un module npm.

Nous avons vu dans le chapitre 5 que Node utilisait la valeur main du fichier package.json pour déterminer quel script inclure en faisant require('<module>') ou import <module> from '<module>'.

Le champ bin est une transposition de main pour associer un script exécutable à notre module npm :

Le moyen le plus simple pour tester l’intégration de l’exécutable avec notre système d’exploitation est de l'installer globalement. L’exécutable npm sait aussi installer un module à partir d’un chemin vers un répertoire contenant un fichier package.json :

Par défaut, l’exécutable est disponible sous le nom du module en question, déclaré dans le champ name du fichier package.json :

Nous avons vu comment récupérer les arguments d’un script Node en découvrant le module process au chapitre 4. Pour rappel, la variable process.argv est un tableau qui contient tous les arguments passés au script principal :

Cela donne le résultat suivant quand nous lançons ce script dans un terminal :

Ce tableau est un peu “léger” car il se contente de retourner les arguments, sans compréhension de la logique recherchée. C’est à nous de dire que FR est une valeur associée à --country.

Dans le contexte des outils en ligne de commandes, les arguments et les options sont des paramètres qui sont interprétés par le programme pour contextualiser son action. Ils fonctionnent un peu comme des arguments de fonction et des paramètres d’URL.

L’enjeu des arguments et des options est de les transformer en une structure de données afin de les passer en tant que paramètres d’une fonction.

Nous allons utiliser le module npm minimist (npmjs.com/minimist) dans les exemples suivants. Il prend en charge la complexité de l’interprétation de process.argv et je le trouve robuste, bien testé et minimaliste.

Commençons par les options et voyons ce que minimist affiche :

Les options sont adaptées pour nommer des paramètres facultatifs dont l’ordre n’a pas d’importance, sous forme d’un “interrupteur” dans le cas d’un booléen ou d’une valeur – nombre ou chaîne de caractères, peu importe.

Les options s’écrivent sous une forme raccourcie (alias). Un alias réduit l’encombrement visuel et est signalé avec un seul tiret (au lieu de deux pour leur forme complète) :

La lecture est rendue plus difficile pour celui ou celle qui n’a pas consulté le manuel d’utilisation en détail – ce qui est souvent le cas, surtout pour des personnes qui découvrent un nouveau logiciel.

J’ai tendance à utiliser les alias pour les options principales ou importantes. Je privilégie la forme longue dans les exemples et dans la documentation, afin d’augmenter les chances de compréhension.

Les valeurs par défaut simplifient le paramétrage en rendant certaines valeurs implicites :

L’enjeu réside donc dans l’utilisation des valeurs à bon escient, pour que le programme fasse ce qui est attendu d’un point de vue utilisateur. Le paramétrage est similaire à celui des alias.

Un autre concept utile est celui des types. Nous définissons explicitement nos attentes sur ce que telle ou telle option est censée recevoir :

L’exemple précédent renforce nos attentes : l’option --country sans valeur ne sera pas comprise comme un booléen et, au contraire, l’option booléenne --fast n’accepte pas de valeur – cette dernière est interprétée comme un argument.

Les arguments sont adaptés à des situations où des valeurs sont obligatoires, n’ont pas besoin d’être nommées et pour en accepter un nombre arbitraire. Si les valeurs ne correspondent pas à une liste, le positionnement des arguments est important car il détermine leur identification. Les arguments se prêtent particulièrement bien à exprimer une liste de fichiers ou d’identifiants.

Le paramètre passé en argument est l’expression d’un fuseau horaire selon l’organisme de standardisation IANA (www.iana.org/time-zones). Une liste de fuseaux se trouve sur time.is/time_zones. L’idée est d’afficher l’heure courante selon le fuseau horaire donné en argument. C’est un paramètre obligatoire qu’il n’est pas nécessaire de nommer :

Nous pouvons travailler avec les fuseaux horaires sans module additionnel, grâce à la fonctionnalité de formatage internationalisé (chapitre 3) :

Cet exemple se transformerait de la manière suivante si nous souhaitions étendre l’affichage de l’heure à autant de fuseaux horaires que voulus :

Ce script accepte un nombre indéfini d’arguments et son temps d’exécution dépendra de la longueur de cette liste. Elle n’a d’ailleurs pas forcément à être connue à l’avance et les valeurs s’obtiennent dynamiquement, en les listant depuis un fichier, par exemple :

Le contenu du fichier s’obtient d’une traite en bash avec l’utilisation combinée de capture de valeur ($( )) et de l’opérateur de redirection < :

C’est minimal, mais le fichier doit être lu dans son intégralité et copié entièrement dans la mémoire de Node avant d’en faire quelque chose. Une approche plus économique est d’utiliser les flux de données (chapitre 4. Nous y reviendrons plus loin.

L’utilisation des sous-commandes est la bienvenue pour organiser des actions de manière indépendante, là où les choses deviendraient implicites et chaotiques avec les options. C’est l’équivalent d’une route dans une application web (chapitre 7).

Les commandes suivantes illustrent la génération de résultats aléatoires. Leur nature varie en fonction de la sous-commande employée ;

Nous associons une fonction différente à chaque sous-commande pour renforcer cette notion d’actions indépendantes mais qui partagent les options et arguments du script.

L'exécutable npm est un exemple d’application qui repose sur des sous-commandes pour déterminer quelle action exécuter – installer un module, lancer une recherche ou encore initialiser un projet, entre autres.

Des applications en ligne de commande plus complexes soulèvent de nouveaux besoins pour éviter les effets de bord et pour faciliter la modularité de notre code : la validation des paramètres, une gestion plus fine des sous-commandes, ainsi que la génération automatique de la documentation. Nous y reviendrons dans la section “Utilisation d’un framework”.

Les couleurs vont nous aider à faire ressortir, différencier et distinguer des éléments au sein d’une interface monochrome.

L’alternance de texte coloré et monochrome a été créée à partir du script suivant :

Par défaut, tout caractère envoyé vers la console est affiché. Un mécanisme de commandes s’active en envoyant un caractère invisible suivi d’une série de symboles. Ces commandes changent la couleur du texte, sa couleur de fond, l’emphase, le soulignement et même la position du curseur.

Les huit couleurs principales et les huit couleurs vives s’affichent dans à peu près tous les terminaux. Cela vaut aussi pour leur utilisation en couleur de fond.

Un autre type de commande sélectionne dans une palette de 256 couleurs mais aussi dans la palette RGB (Red Green Blue, Rouge Vert Bleu). Ces commandes débutent par [38;5 et [38;2, respectivement :

Le module npm chalk (npmjs.com/chalk) facilite l’utilisation des codes ANSI en leur donnant des libellés mémorisables, en gérant la compatibilité du nombre des couleurs supportées par le terminal voire en désactivant les couleurs si nécessaire.

Le module s’utilise aussi comme modèle avec les guillemets obliques, ce qui augmente encore plus la clarté d’affichage.

Les programmes interactifs demandent des informations de manière guidée à la personne utilisant l’exécutable, en plus des arguments et options. Poser une série de questions est une manière d’accompagner une personne dans une décision, d’exposer des choix dynamiques et de réduire les erreurs dans la création de fichiers, par exemple.

Le module readline proposé par Node est peu connu. Il sert à transformer les flux d’entrée et de sortie (chapitre 4. Le système de curseur sait mettre en pause, revenir en arrière et effacer tout ou une partie d’une ligne, entre autres. Ce module sait aussi poser des questions (!) :

Nous allons utiliser le module npm inquirer (npmjs.com/inquirer) dans la suite de cette section. Il se base sur readline et simplifie grandement l’interactivité : question, liste à choix unique navigable au clavier, boîte à cocher, confirmation, validation de réponse et exécution conditionnelle, si telle ou telle question contient les valeurs qui nous intéressent, par exemple.

L’exemple précédent peut être réécrit de la sorte :

Ce n’est pas beaucoup plus compliqué de poser plusieurs questions et de les personnaliser avec les réponses aux précédentes questions :

Dans cet exemple, rien ne nous empêchait de saisir autre chose qu’un nombre dans la question de l’âge. C’est gênant, mais cela se résout à l’aide de la propriété de configuration validate.

Cette fonction est appelée à chaque tentative de réponse. La question est inlassablement posée tant que la fonction validate retourne autre chose que le booléen true :

Enfin, deux modes de liste sont proposés par le module inquirer : list et checkbox. Dans le premier cas, nous naviguons au clavier pour sélectionner une seule réponse. Dans le deuxième, nous naviguons au clavier et sélectionnons les choix à l’aide de la touche Espace :

Le potentiel de combinaison de ces éléments est vraiment intéressant. Nous pourrions créer des quiz, des interfaces de recherche ou faciliter la création de fichiers de configuration sans avoir à mettre les mains dans le cambouis. Les choix mis à disposition dans l’interface se créent aussi dynamiquement, à partir de données obtenues depuis une ressource distante – ils n’est pas nécessaire de les écrire en dur dans le code.

Je trouve que transmettre un feedback est un élément différenciant dans la conception d’une application – qu’elle soit utilisée sur le Web ou dans un terminal. Informer de la progression est un des moyens d’y parvenir. La progression concerne aussi bien l’indication du franchissement d’étapes que celle de pourcentage d’accomplissement d’une tâche.

Cette approche est une première tentative d’indiquer une progression à travers deux mécanismes : le passage du vide au plein en utilisant un caractère qui véhicule ce changement et l’utilisation d’un signal visuel pour informer de l’accomplissement de la tâche.

La seule chose qu’il manque à mon goût est d’avoir un réel sens de progression, c’est-à-dire une actualisation du contenu qui informe de l’avancement.

Nous avons parlé des commandes ANSI pour changer les couleurs. Il se trouve que certaines de ces commandes contrôlent aussi la position du curseur. Ainsi, au lieu d’écrire à la suite, nous pouvons revenir en arrière et même effacer le contenu d’une ligne.

Il n’y a pas beaucoup de code à changer dans l’exemple précédent pour y parvenir.

À partir de là, nous sommes libres d’écrire nos propres barres de progression, des indicateurs d’activité et de ne garder à l’écran que les informations reflétant l’état actuel de l’application.

Deux modules npm simplifient la vie quand on n’apprécie pas trop les commandes ANSI :

Terminons cette section avec l’utilisation d’un indicateur d’activité et une information de réussite ou non de notre action. Nous nous aidons du module npm ora (npmjs.com/ora). Il est rapide à configurer et propose une palette intéressante d’animations.

Nous nous retrouvons à enlever encore quelques lignes par rapport aux exemples précédents :

Nous pouvons aussi tirer parti du fonctionnement du module ora en reproduisant l’animation et en personnalisant le symbole de réussite.

L’affichage d’informations sous forme de tableau est idéal pour le confort de lecture de listes. Notre lecture gagne en qualité quand notre vision s’attend à retrouver une structure prédictible.

Cet exemple est généré à l’aide du module npm table (npmjs.com/table). Il s’utilise sans configuration pour démarrer. Il a la capacité de tronquer et limiter la largeur des colonnes, mais aussi de gérer l’alignement des contenus dans les cellules.

Il est à noter que le module table expose aussi une interface en flux, pour ajouter des lignes au fur et à mesure – par exemple en cas de lecture continue ou sur un fichier volumineux.

L’inconvénient d'installer un module exécutable, c’est la difficulté de savoir si une mise à jour intéressante a été publiée (probablement parce que je ne pense pas à lancer la commande npm outdated --global). Il existe toutefois des moyens de signaler aux personnes qui utilisent votre exécutable qu’une version plus récente existe.

J’aime l’approche minimaliste du module npm update-check (npmjs.com/update-check). Il compare le numéro de version passé en paramètre avec celui de la dernière version de ce même module, sur le registre npm.

Dans cet exemple, update-check interroge le registre npm pour déterminer la version la plus récente de nodebook. S’il estime que la version installée localement est plus ancienne, il retourne un objet avec le numéro de version à installer.

En temps normal, c’est-à-dire dans le cas d’un module dont nous sommes à l’origine et que nous publions sur le registre npm, nous aurions tendance à utiliser le contenu du fichier package.json en argument de la fonction check.

Maintenant, nous pouvons présenter une information plus digeste et actionnable à la personne qui utilise notre module :

Les utilisatrices et utilisateurs sont informés de la disponibilité d’une mise à jour dès qu’elles se servenrt du module exécutable en question. La décision d’actualiser leur appartient toutefois.

Un programme qui accepte beaucoup d’options devient de plus en plus compliqué à maintenir car il est difficile de tester tous les cas de figure à la main.

Un programme exécutable robuste est un script qui contient le moins possible de code spécifique à la gestion de la ligne de commandes. Pour ce faire, nous allons séparer la logique d’exécution en la plaçant dans une fonction, dans un autre module.

Nous avons opéré un changement : l’utilisation de console.log() pour l’affichage des résultats revient du côté de l’exécutable.

Notre code est portable s’il retourne un résultat et en laissant la responsabilité de l’affichage au code le plus proche de l’utilisateur – c’est le cas ici avec la fonction getTime().

Cette écriture facilite l’écriture de tests. Justement, parlons-en.

L’écriture de tests nous aide à découvrir qu’une modification produit un résultat différent de celui attendu. Les tests documentent aussi les cas à la marge de notre code. En général, dès qu’il y a un if …​ else, cela implique d’écrire au moins une nouvelle assertion.

Pour des besoins simples, j’utilise le module npm tape (npmjs.com/tape). Il gère l’exécution des tests et il fournit quelques méthodes pour exprimer nos attentes – les assertions.

Dans ce cas précis, j’ai écrit deux assertions qui illustrent les différents cas de figure représentés dans le fichier 01/lib.js – quand l’erreur est provoquée et quand le résultat est retourné :

Nous sommes parés à toute éventualité, mais en y réfléchissant, le module cli.js ne gère pas vraiment le cas où aucun argument n’est transmis.

Je trouve peu élégant d’être accueilli·e avec une trace d’erreur comme celle-ci. L’erreur mériterait d’être présentée en contexte, celui de notre utilisation et non celui des rouages internes de Node.

La présentation des messages de réussite et d’erreur nécessite d’être à l’écoute des signaux envoyés par notre code afin de le restituer de manière adaptée.

Afin de parvenir à ce résultat, j’ai opté pour l’utilisation de promesse (chapitre 3). Je trouve cette méthode plus élégante car nous gérons le résultat et le message d’erreur d’une manière visuellement similaire, mais séparée.

Ce changement n’implique pas de bouleversement dans notre code. L’appel à throw est remplacé par reject() et le return se transforme en resolve().

Nous n’avons plus à modifier le fichier cli.js pour gérer de nouveaux messages d’erreur. Nous pourrions mieux gérer certains cas de figure, par exemple quand un fuseau horaire inconnu est spécifié.

Tester l’exécutable est un moyen de vérifier que les câblages entre notre exécutable et notre mode Node sont bien faits. L’idée n’est pas de tester à nouveau les mêmes aspects du code, mais bel et bien de nous assurer que les conditions d’utilisation du programme sont remplies.

Nous avons à nouveau recours au module tape. Cette fois-ci, nous l’accompagnons d’un autre module, tape-spawn (npmjs.com/tape-spawn). Ce dernier intègre à tape le test de processus externes. En l’occurrence ici, cela concerne nos exécutables en ligne de commandes.

L’utilisation conjointe des tests unitaires et de ceux de l’exécutable nous permet de gagner en confiance dans la robustesse de notre code, de déceler de nouveaux cas à la marge et de nous rendre compte de certaines incohérences d’interface utilisateur.

La documentation d’un logiciel est aussi importante que son code. C’est le premier élément qui donne une idée de la simplicité ou de la complexité d’utilisation d’un logiciel, de ce qu’il est possible de faire avec et des concepts qui s’y rapportent.

Le premier endroit où documenter son application est dans l’exécutable lui-même, avec l’option --help – ou son raccourci -h. C’est une convention pour afficher une aide synthétique, rapide d’accès et facile à comprendre.

L’aide proposée ici est minimale et n’indique que trop peu l’intention du programme. Nous n’avons aucune idée de l’effet de telle ou telle option, du résultat qui va se produire ou encore des valeurs acceptées par le programme.

Une aide qui me rassure et m’informe ressemble plutôt à ce qui suit :

Elle véhicule l'intention du programme, des exemples qui précisent un concept que je ne connais pas (fuseau horaire IANA) et j’y découvre même l’existence d’une commande qui liste ces fameux fuseaux horaires. Au premier coup d’œil, je ne décèle pas d’impasse et j’y vois plutôt une invitation à essayer sans appréhension.

Cette aide a été générée automatiquement en utilisant le framework yargs – nous en parlerons dans la section suivante. Ses méthodes .usage() et .example() ainsi que la propriété description de chaque option suffisent à constituer un affichage clair et informatif.

Un autre lieu courant pour documenter un projet est le README. C’est un fichier texte souvent affiché en premier sur la page d’accueil d’un projet logiciel. Sa mise en forme s’améliore avec l’utilisation d’une syntaxe de balisage léger comme Markdown.

Ce type de fichier est très largement suffisant pour documenter un projet. C’est l’équivalent de l’option --help, à l’échelle de l’application – son intention générale, sa compatibilité de version avec Node, comment l’installer, où poser des questions et peut-être même davantage d’exemples pour mieux comprendre ce qui ne tiendrait pas dans l’option --help.

Je trouve que le README est un excellent endroit pour reporter l’affichage de la commande --help.

Nul besoin de faire compliqué pour véhiculer autant d’informations essentielles avec un minimum d’efforts. Démarrer un projet en écrivant cette documentation est un excellent moyen pour travailler à la clarification de ses idées et pour commencer à imaginer la forme que va prendre l'écriture des tests.

Une application en ligne de commande dont le nombre de lignes de code augmente devient de plus en plus complexe à maintenir. Potentiellement, l’expérience d’utilisation se dégrade aussi. Il faut continuer à prendre soin de la cohérence des arguments, des options et de valider que ce sont les valeurs attendues. Cette complexité appelle aussi à afficher une aide à la demande ou de manière contextuelle, par exemple au niveau de la sous-commande.

Des modules npm comme yargs (npmjs.com/yargs) aident à structurer la création d’applications en ligne de commande en intégrant la majorité des fonctionnalités vues dans la section “Du script au programme interactif”. La génération de l’aide, le parsing d’arguments et d’options et leur validation sont connectés ensemble, de manière transparente.

Ce genre de module est intéressant à utiliser quand l’assemblage d’autres modules indépendants rend le programme trop fragile et trop compliqué à tester.

La commande d’aide est générée automatiquement à partir de la définition d’arguments et d’options.

Le mécanisme de coercition définit la règle de transformation d’une option vers une autre représentation, plus pratique à utiliser. C’est le cas des dates par exemple : nous les recevons sous forme de chaîne de caractères alors qu’il serait plus facile de travailler avec des objets Date (chapitre 3).

Par défaut, la date est calée sur l’instant présent :

Une date peut même être incomplète :

Voici un autre exemple du mécanisme de coercition, cette fois-ci appliqué à un chemin d’accès de fichier :

Le chemin d’accès passé en option est intercepté par une fonction. Elle le reçoit en argument et a la responsabilité d’en lire le contenu et de le transformer en objet ECMAScript grâce à la fonction JSON.parse() (chapitre 3).

Cette pratique renforce une approche applicative modulaire. L'interface absorbe les spécificités de la ligne de commandes. L'application réagit aux paramètres sans avoir à se préoccuper du contexte, que ce soit sur le Web ou dans un terminal.

Les frameworks d’application en ligne de commande facilitent l’organisation et la définition de sous-commandes.

C’est l’occasion d’adapter l’exemple utilisé dans la section “Utiliser des arguments et des options”. L’intention est de modifier le moins possible le code initial.

Je trouve qu’il est plus facile d’exécuter une fonction avec les bons arguments en utilisant ce mécanisme de sous-commandes. Nous n’avons même pas eu à modifier la signature des fonctions words et number.

Un résultat identique s’obtient en organisant les sous-commandes dans des fichiers individuels et en indiquant à yargs dans quel répertoire les charger.

Nous ne déclarons plus les commandes sous forme d’un appel de fonction mais en retournant un module Node. Chacune de ses clés configure un aspect de la commande :

Il y a des cas où passer des chemins d’accès à des fichiers en arguments d’un exécutable ne suffit pas. C’est le cas notamment quand on ne connaît pas la liste exacte des fichiers ou lorsqu’elle est susceptible de changer.

Cet exemple illustre l’utilisation d’un chemin relatif et d’un chemin absolu, tous deux normalisés en chemins absolus. En procédant ainsi, nous rendons notre code indépendant de son contexte d’exécution – ici, notre emplacement au sein du système de fichiers.

La saisie des chemins se simplifie en utilisant deux mécanismes : l'expansion et le globbing. Le module npm glob (npmjs.com/glob) fait très bien ce travail, mais nous allons nous baser sur globby (npmjs.com/globby) à la place. Il gère les promesses et je le trouve plus simple d’utilisation.

Dans cet exemple, nous partons à la recherche de tous les fichiers préfixés par package- et terminés par .json. Cette intention est exprimée par un seul argument qui contient le caractère de globbing (*).

L’expansion est caractérisée par l’utilisation des accolades. Les valeurs sont séparées par des virgules, qui signifient ou. Les deux syntaxes se combinent ici pour récupérer les fichiers suffixés par .adoc ou par .html :

Enfin, l’utilisation de la double-étoile (**) signifie dans tous les répertoires. Nous récupérons ainsi tous les fichiers .js contenus dans ce répertoire et les sous-répertoires :

Cette section complète notre découverte du module stream (chapitre 4). Mon intention est de vous aiguiller dans la conception d’applications en ligne de commande qui acceptent des flux de données, en entrée comme en sortie. La ligne de commande se prête tout particulièrement au streaming et nos applications gagnent à fonctionner longtemps en consommant le moins de ressources possibles.

J’aime bien proposer une alternative à l’entrée standard, en utilisant les arguments lorsqu’il y a un nombre indéfini d’éléments à lire. Je trouve que cette proposition évite de renoncer à un outil dans un contexte où il est impossible de configurer un flux d’entrée.

La stratégie consiste à utiliser l’entrée standard quand on détecte une absence d’arguments et, sinon, d’utiliser ces derniers.

Notons au passage l’utilisation de Promise.resolve() (chapitre 3) pour transformer deux sources de données de manière identique.

Les options sont adaptées pour indiquer l’emplacement d’une ressource. La méthode fs.createReadStream() (chapitre 4) lit les données d’une ressource de la même manière que nous consommons l’entrée standard.

Là aussi, je trouve intéressant de proposer une approche double, en acceptant un chemin de fichier en option et son contenu via l’entrée standard :

Ce qui est intéressant avec cette approche est qu’elle nous apprend à intervenir nous-même sur un flux sans avoir à en connaître les tenants et aboutissant.

Le précédent exemple nous permet aussi de nous libérer des modules get-stdin et get-stream. Ces derniers obligent quand même à charger tout le contenu du flux entrant en mémoire. En travaillant directement sur les flux avec le module through2, les transformations sont faites en temps réel, au fur et à mesure où les données sont lues, bloc par bloc.

Nous sommes désormais en mesure de travailler avec des fichiers au même titre qu’avec l’entrée et la sortie standards.

L’utilisation d’un même concept pour lire et pour écrire des données simplifie notre code tout en offrant des performances optimales.

Il ne reste plus grand-chose à faire pour appliquer cet effort à la sortie du programme, pour écrire en continu dans un fichier ou bien vers la sortie standard.

En quelques exemples, nous sommes passé·e·s d’une utilisation potentiellement énergivore à un traitement en continu, plus doux pour les ressources système et intégrable à tous les outils en ligne de commande qui lisent depuis l’entrée standard ou écrivent vers la sortie standard.

Faire en sorte que les options possibles s’affichent à l’écran sur une simple pression de la touche Tab est la cerise sur le gâteau ! Cette technique facilite la découverte d’une application par tâtonnement. Elle accélère et réduit le risque d’erreurs durant la saisie des commandes.

Le mécanisme d’autocomplétion est fourni par l’environnement d’exécution de notre terminal, le shell. Sous Linux et macOS, il s’agit de bash, de zsh ou plus rarement, de fish. Il “suffit” donc d’interconnecter notre programme exécutable pour qu’il fournisse les résultats de complétion au mécanisme de notre shell.

Le mécanisme de complétion est fourni par le module npm omelette (npmjs.com/omelette). Il est totalement indépendant de notre outillage d'arguments et d’options. Je le trouve léger et rapide à prendre en main.

L’autocomplétion peut aller jusqu’à suggérer les valeurs associées aux options et arguments de notre programme.

Pour cela, le module omelette accepte un arbre de déclarations afin de comprendre quoi suggérer en fonction de ce qui a été précédemment saisi :

C’est très pratique quand on ne sait pas par où commencer et quand on ne connaît pas la liste exhaustive des propositions.

Nous avons parlé du module npm yargs dans la section sur l'utilisation d’un framework. Il embarque un module d’autocomplétion. Si vous utilisez déjà ce module, l’autocomplétion revient à ajouter une ligne de code à notre programme. Elle est un peu plus basique et demande plus de travail pour arriver à la qualité des résultats du module omelette.

Nos programmes exécutables souffrent d’un défaut : ils imposent l’installation préalable de Node pour fonctionner. Ce n’est pas grave pour une machine de devéloppement ou sur une machine de production car nous sommes à même de contrôler l’environnement d’exécution.

La première solution consiste à empaqueter notre application avec le module npm pkg (npmjs.com/pkg). Cet exécutable embarque notre code, les dépendances npm du projet et la version de Node de notre choix sous la forme d’un unique fichier exécutable.

Dans ce cas, nous avons empaqueté une même application à la fois pour les systèmes d’exploitation Windows, Linux et macOS. Nous pourrions faire de même pour des ordinateurs légers de type Raspberry Pi.

Une solution alternative consiste à utiliser le logiciel Docker (docker.com/community-edition). Ce système crée une base d’environnement réutilisable (le conteneur) à partir d’une recette d’installation (l’image). Une même image applicative se réplique à l’infini, sans avoir connaissance de notre système d’exploitation.

Une image se construit depuis un fichier Dockerfile avec la commande docker build. Elle s’exécute sous forme d’un conteneur jetable avec la commande docker run. La recette d’installation est une suite d’instructions jouées les unes à la suite des autres :

Je recommande de doubler le fichier Dockerfile d’un fichier .dockerignore. Il suit les mêmes règles de fonctionnement qu’un fichier .gitignore. Il exclut une liste définie de fichiers du contexte d’exécution et d’une possible copie vers l’image Docker.

Une fois construite, une image se distribue sous forme de fichier transférable, sur le registre public hub.docker.com ou sur tout autre registre privé – dont ceux fournis par certains hébergeurs cloud (chapitre 6).