Moi, j’y passe pas mal de temps. En tant que développeur, j’ai utilisé un tas d’outils en ligne de commande. Quand on administre un serveur, par exemple, il n’y a souvent aucune interface graphique : on s’y connecte à distance (en ssh, je glisse un petit mot au passage pour la culture), et tout se fait en tapant des commandes.

Cet écran qui intimide tant est devenu le terrain de jeu préféré des agents IA. Dans l’article sur les MCP, je disais d’ailleurs que je passe désormais surtout par des CLI. Il est temps d’expliquer ce que c’est.

Pourquoi connecter son agent, déjà ?

Petit rappel, si vous arrivez directement ici.

Un agent IA repose sur un modèle qui a appris énormément de choses sur le monde. Mais il ne sait rien de vous : ni vos mails, ni votre agenda, ni vos projets. En le branchant à vos outils, il travaille avec vos vraies données, et il peut agir à votre place.

C’est le sujet de l’article qui ouvre cette série, si vous voulez creuser.

Une machine à café sans boutons

CLI veut dire Command Line Interface, interface en ligne de commande en français. C’est une façon d’utiliser un programme en lui écrivant des ordres, plutôt qu’en cliquant sur des boutons.

Pour l’imaginer, prenez une machine à café multifonction, celle du bureau. Elle a un bel écran tactile, des boutons, des images de cappuccino, allongé, latte, déca, etc. C’est pensé pour des humains : on regarde, on appuie, on boit et on discute avec les collègues du dernier bug en prod.

Maintenant, retirez l’écran et les boutons. Il ne reste qu’une fente, dans laquelle on glisse un ticket. Sur ce ticket, on écrit ce qu’on veut :

café faire --taille grand --sucre 1

La machine lit le ticket, prépare le café, et ressort un petit ticket de réponse : « Grand café, 1 sucre. Bonne journée. »

On peut aussi lui glisser café lister, et elle imprime la liste de toutes les boissons qu’elle sait faire. Ou café --help, et elle imprime sa notice : toutes les commandes possibles, avec leurs options.

Un CLI, c’est cette fente à tickets. Le terminal, c’est la fenêtre dans laquelle on écrit les tickets (le fameux écran noir). Et chaque service peut avoir sa propre machine : un CLI pour GitHub, un pour Google Workspace, etc.

Une vraie commande ressemble à ça :

gh pr list

gh, c’est le CLI de GitHub (le service où les développeurs versionnent leur code). pr list lui demande la liste des demandes de revue en cours sur un projet. Il répond par quelques lignes de texte, une par demande.

Pour un humain, la machine sans boutons est clairement moins pratique. Il faut connaître les commandes, les écrire sans faute, et c’est moins joli. Mais pour un agent ?

Pourquoi les agents adorent ça

Écrire un ticket, c’est exactement ce qu’il sait faire. Un modèle de langage lit et écrit du texte. Lui faire appuyer sur des boutons dans une interface, c’est possible, mais c’est lent et laborieux. Lui faire écrire une commande, c’est naturel. Et la réponse revient en texte, qu’il lit sans effort.

Il connaît déjà la machine. Les CLI répandus existent souvent depuis des années, bien avant les agents. gh en est un bon exemple. Leurs commandes apparaissent dans des tonnes de documentations, de tutoriels et de forums, donc dans ce que les modèles ont ingéré pendant leur entraînement. Pas besoin de tout leur expliquer : ils savent déjà s’en servir.

La notice ne se lit qu’au besoin. Avec un MCP, l’agent reçoit souvent dès le début de la conversation la description de tous les outils disponibles. C’est comme si chaque machine vous imprimait sa carte complète au moment où vous entrez dans la pièce. Avec un CLI, l’agent ne demande --help que lorsqu’il en a besoin, et seulement pour la machine qui l’intéresse. Résultat : beaucoup moins de tokens consommés, une mémoire de travail moins encombrée. Les comparaisons qu’on trouve en ligne vont dans ce sens, même si l’écart varie beaucoup d’un test à l’autre.

Les erreurs aussi sont des tickets. Une commande mal écrite ? La machine ressort un ticket : « option inconnue », « projet introuvable ». L’agent le lit, corrige, et réessaie. Pas besoin d’interpréter une fenêtre d’erreur rouge.

Dans mon cas

Mes agents utilisent déjà mon terminal en permanence, pour des choses très basiques : chercher des fichiers, gérer l’historique d’un projet avec git, lancer un petit programme Python, vérifier la qualité du code. Ce sont des commandes que j’utilise moi-même depuis longtemps.

Et j’ai installé d’autres CLI exprès pour eux. gh, par exemple. Avec lui, mon agent peut créer une demande de modification sur GitHub, la surveiller, voir les erreurs quand les vérifications automatiques échouent, et réagir pour les corriger.

Petit bonus : ce sont des outils que je sais utiliser aussi. L’agent et moi parlons la même langue, avec les mêmes commandes.

Comment on en ajoute un

Il faut un agent qui a accès à un terminal. C’est le point de départ. Les agents qui travaillent sur votre machine, comme Claude Code ou Codex, en ont un. Le chat web de Claude ou ChatGPT, non. (Petit clin d’œil au passage : Claude Code et Codex sont eux-mêmes des CLI.)

On installe le CLI. En général, une commande copiée depuis la documentation du service. Ou, plus simple : on demande à son agent. « Installe le CLI de GitHub », et il s’en occupe.

On se connecte. Le CLI doit savoir pour qui il travaille. Souvent, une commande ouvre votre navigateur, vous vous connectez à votre compte, et c’est réglé. Parfois, il réclame une clé d’API, le fameux badge d’hôtel de l’article précédent.

L’agent s’en sert. S’il connaît déjà le CLI, rien à faire. Sinon, il lit la notice. Certains CLI récents sont même pensés pour les agents dès le départ : ils peuvent être livrés avec des skills, des petits modes d’emploi prêts à donner à votre agent.

Les limites

Pas de terminal, pas de CLI. Si vous utilisez l’IA depuis le chat web ou l’application mobile, cette voie vous est fermée. Les connecteurs ou les MCP distants restent alors la solution alternative.

C’est souvent très permissif. Un CLI fait en général tout ce que votre compte permet de faire. Lire, oui, mais aussi supprimer, publier, modifier des réglages. Et l’agent l’utilise avec vos droits. La plupart des agents demandent votre accord avant de lancer une commande, au moins au début : prenez le temps de lire ce que vous validez. Et quand le service le permet, limitez les droits de la connexion ou de la clé.

Tous les services n’en ont pas. Les outils de développeurs en ont presque tous. Pour d’autres services plus grand public, c’est moins systématique.

Attention à ce que vous installez. Un CLI tourne sur votre machine, avec vos droits. Même réflexe que pour les skills et les MCP : on préfère l’outil officiel du service, et on vérifie la source avant d’installer quoi que ce soit. L’avantage ici, c’est que la plupart des CLI existent depuis assez longtemps pour avoir été éprouvés et audités, bien avant l’arrivée de l’IA.

CLI ou MCP ?

Pour le moment, quand j’ai le choix, je prends le CLI. Il existait souvent avant, il a fait ses preuves, l’agent sait déjà s’en servir, c’est rapide et ça consomme beaucoup moins de tokens.

Mais je ne les oppose pas. Rien n’oblige à n’utiliser que l’un ou l’autre, et chacun a ses bonnes raisons d’exister :

• certains services n’ont qu’un MCP ;
• on n’a pas forcément envie de donner à un agent l’accès à un terminal ;
• le web et l’app mobile ne permettent pas d’utiliser des CLI ;
• un MCP peut volontairement ne proposer que quelques actions, là où un CLI ouvre souvent tout.

Ce dernier point, je l’ai vécu. Dans l’article sur les MCP, je racontais ce petit MCP que j’avais fait pour un agent de mon homelab : trois actions git, pas une de plus, et pas de terminal. Avec le CLI git, il aurait pu tout faire, y compris des bêtises. Là, il ne pouvait littéralement pas.

Pas besoin d’aimer l’écran noir

Un CLI, c’est une machine sans boutons, qu’on pilote en lui glissant des tickets. Peu engageant pour nous, parfait pour un agent qui ne fait qu’écrire et lire du texte. Et vous n’avez même pas besoin d’écrire les tickets vous-même : c’est son travail.

Jusqu’ici, dans cette série, c’est toujours l’agent qui va chercher l’information ou qui agit quand on le lui demande. Il est à l’initiative de la demande, en début de chaîne. Mais si c’était au service de le prévenir quand il se passe quelque chose ? Un mail qui arrive, un paiement reçu, un formulaire rempli. C’est le rôle du webhook, et ce sera le prochain article.

Connecter un agent IA à d’autres services :

• Comment connecter son agent IA à ses outils (Gmail, Notion, Google Agenda…) ?
• C’est quoi un connecteur IA ? Relier Claude ou ChatGPT à vos outils en quelques clics
• C’est quoi un MCP ? Le port USB-C qui branche votre agent IA à vos outils
• C’est quoi une clé d’API ? Le badge d’hôtel qui ouvre vos outils à votre agent IA
• C’est quoi un CLI ? La machine à café sans boutons que votre agent IA adore
• C’est quoi un webhook ?

Hors-série complémentaire :

• C’est quoi une API (Application Programming Interface) ?

La réponse est oui, et j’en utilise un depuis bientôt deux ans maintenant. Il s’appelle mise-en-place, ou mise pour les intimes. Au départ, je l’ai adopté pour une raison très simple : j’en avais marre de chercher un nouveau version manager pour chaque écosystème.

nvm pour Node.js. pyenv pour Python. fvm pour Flutter. rustup pour Rust. chruby pour Ruby. Un autre pour je ne sais quel SDK qui arrive sur un projet. Vous avez la musique. Chaque outil est souvent très bien dans son coin, mais l’ensemble finit par créer une petite fatigue. Rien de dramatique, on va s’en remettre, mais le genre de friction qui revient souvent.

Installer. Mettre à jour. Changer de version. Expliquer à un collègue quoi installer. Retrouver où la version est déclarée. Se souvenir si cette commande s’applique globalement ou seulement dans le projet. La promesse de mise est assez agréable : apprendre une seule façon de faire, puis l’appliquer aux autres d’outils.

Un version manager généraliste

mise se place dans la famille des gestionnaires de versions généralistes, comme asdf ou vfox. L’idée n’est donc pas de gérer uniquement Node.js, Ruby ou Python, mais de fournir une interface commune pour tout un ensemble de langages, runtimes, SDK et outils de développement.

Dans un projet, je peux vouloir Python 3.12, Node.js 22, Flutter 3.32, Terraform, Bun, ou encore un outil CLI dont l’équipe a besoin. Plutôt que d’empiler les gestionnaires spécialisés, je peux demander à mise de s’en occuper. Derrière, il sait s’appuyer sur plusieurs sources et backends selon les outils. Honnêtement, au quotidien, je n’ai pas besoin d’y penser. Et c’est plutôt bon signe.

Ce n’est pas le seul outil capable de faire ça. J’avais déjà repéré asdf dans mon ancien article sur les version manager, et vfox existe aussi dans le même esprit. Pourquoi j’ai choisi mise ? Parce qu’il m’a semblé rapide, actif côté communauté, très fourni en outils supportés, et parce qu’il ne s’arrête pas au simple rôle de version manager. Je reviendrais dessus juste après.

Mais avant, commençons par le commencement. Installer mise. (Vérifiez tout de même le site officiel si la méthode a changé entre temps) :

curl https://mise.run | sh

Si je veux installer Node.js globalement (tout mon PC), la commande ressemble à ça :

mise use -g node@26

Si je veux installer Python pour un projet (un dossier et ses enfants) :

mise use python@3.13

À partir de là, quand j’entre dans le dossier du projet, python pointe vers la bonne version. Je tape python, pas mise python, pas pyenv exec python, pas une commande enveloppée avec un préfixe qui me sort du geste naturel. C’est un détail, mais je trouve que ça compte. Quand je lance flutter test, j’ai envie d’écrire flutter test, pas de me rappeler que sur ce projet précis je dois écrire fvm flutter test.

Le fichier mise.toml

Là où mise devient vraiment intéressant, c’est avec le fichier mise.toml.

Au début, on peut le voir comme un simple équivalent plus généraliste des fichiers .ruby-version, .node-version, .tool-versions, etc. On déclare les outils et les versions attendues par le projet, puis on versionne ce fichier avec le code. Comme ça, toute l’équipe partage la même configuration.

Un exemple très simple pourrait ressembler à ça :

[tools]
node = "26"
python = "3.13"

Ce n’est pas spectaculaire, mais c’est très pratique. Le projet dit explicitement “pour travailler ici, voici les outils et versions attendues”. Le nouveau collègue qui arrive, la machine fraîchement réinstallée, le runner de CI, le moi du futur qui aura tout oublié… tout le monde lit la même chose.

C’est la fin des discussions du style :

• Tu es sur quelle version de Node ?
• Attends, je croyais qu’on était passé en 26 ?
• Ah non, sur cette branche il faut encore la version 25.
• Pourquoi ça marche chez toi et pas chez moi ?

Bon, je m’emballe, cette dernière question ne disparaît jamais totalement malheureusement. Ce serait trop beau. Mais on passe tout de même d’un réglage individuel en un élément de projet versionnée.

Bien plus qu’un version manager

La surprise, pour moi, c’est que le fichier mise.toml ne s’arrête pas aux outils. On peut aussi y déclarer des variables d’environnement, et même des tâches. C’est là que mise a commencé à dépasser, chez moi, le rôle du “truc qui gère les versions” et où je me suis dis que j’allais le garder.

Les variables d’environnement, c’est le genre de chose qui finit souvent dans un .env, parfois un fichier différent par outils, ou pire dans une note. Avec mise, on peut les ajouter dans la configuration du projet. Pas les secrets, évidemment. Mais les valeurs non sensibles, les chemins, les réglages utiles au développement, oui.

Et puis il y a les tâches. On peut définir des commandes nommées, un peu comme on le ferait avec un Makefile ou des scripts maison. Sauf qu’elles vivent dans le même fichier que la déclaration des outils.

Par exemple :

[tasks.setup]
run = "mise install && npm install"

[tasks.test]
run = "npm test"

Je simplifie volontairement, mais l’idée est là. Sur un projet, il suffit de taper mise setup et cette commande prépare ce qu’il faut. Elle installe les outils attendus et prépare le terrain. C’est le genre de petite attention qui rend un projet plus accueillant. (et encore une fois, plus “future-proof” avec notre mémoire)

J’ai commencé à le faire sur tout mes nouveaux projets. Je crée un mise.toml, je le source, et petit à petit j’y mets les commandes que je rejoue souvent. Pas besoin de se demander si c’est make init, npm run setup, ./scripts/bootstrap.sh ou autre chose. Pour moi, de plus en plus, c’est mise run setup.

Même pour ce blog, j’ai une tâche new pour préparer un nouveau post. Créer le dossier, créer un fichier avec un template de post, mettre la date, puis l’ouvrir dans VS Code. Rien de révolutionnaire, mais j’aime beaucoup écrire de petits scripts pour éviter de répéter les mêmes opérations - je suis un flemmard.

Je vous ai parlé des alias ? Je peux faire encore plus court en tapant seulement setup ou new. Et ça marche pour tout, pas seulement pour les tâches - ce sont simplement des alias après tout.

[shell_alias]
new = "mise run new"

Attendez, ce n’est pas fini. On peut aller plus loin avec des hooks : des commandes qui se lanceront à chaque fois qu’on entre/sort du projet, avant ou après une installation, ou même faire du watch ! Quand je vous disais que cet outil allait les gouverner tous. Mon précieux, mon mise.

Ce qui se passe derrière

Sans rentrer dans un tutoriel complet, ça vaut le coup de comprendre grossièrement comment mise s’intègre au terminal.

Le principe de base est assez classique : mise installe les outils dans un de ses dossiers, puis modifie dynamiquement le contenu du PATH. Quand je suis dans un dossier avec un mise.toml, l’environnement actif change, et la commande node, python ou flutter pointe vers la version déclarée.

C’est aussi pour ça que l’expérience reste très rapide. En fait, elle est même inchangée. On ne lance pas un gros proxy à chaque commande. Le shell sait directement où chercher les exécutables.

Il existe aussi un mode avec des shims si on en a besoin, c’est-à-dire des petits exécutables intermédiaires qui redirigent vers la bonne version. Selon les environnements ou IDE, ça peut être utile. J’ai dû passer par les shims pour l’extension Flutter de VS Code par exemple.

Je trouve cette partie intéressante parce qu’elle répond à une inquiétude que j’avais avec certains version managers : est-ce que je vais ralentir mon terminal ? C’était par exemple le cas avec nvm qui est long à démarrer, même si on ne l’utilise pas.

Bref

Au départ, je cherchais surtout un version manager généraliste. Je voulais arrêter d’accumuler un outil par langage. mise m’a donné ça : une manière commune d’installer, mettre à jour et changer de version. Et il est même allé là où je ne l’attendais pas avec les variables d’environnement et les tâches.

Aujourd’hui, je n’installe quasiment plus de langage ou de SDK à la main. Flutter ? Via mise. Python ? Via mise. Les outils autour d’Ansible dont je parlais récemment ? Via mise aussi.

Quand je démarre un projet, mon premier réflexe est de créer et compléter le mise.toml au fur et à mesure pour réduire les frictions. À force, ça devient moins un outil de gestion de versions qu’un petit chef d’orchestre pour mon environnement de développement.

C’était mon cas avec iTerm2 + oh-my-zsh, et on va voir comment trouver les problèmes à la source.

Identifier les causes

Je n’ai pas forcément fait attention au moment exact où mon terminal a commencé à être capricieux pour se lancer. J’ai l’impression que ça a commencé la semaine marquée par l’arrivée d’un nouveau super pouvoir du MDM sur nos machines pro. Il analysait toutes les commandes exécutées pour vérifier les bons privilèges à appliquer.

Une belle coïncidence, c’était le suspect parfait. Je l’ai un peu blâmé sans trop chercher plus loin. Et puis un jour, il est arrivé ce fameux imprévu qui permet au héros de se lancer dans l’aventure.

J’étais en pair avec un collègue pour l’aider sur une erreur autour de cocoapods et iOS. Je lui fais installer un version manager pour Ruby, on modifie son .zshrc, et on veut supprimer le Podfile.lock pour réinstaller proprement les packages. Mais dans la rapidité de l’action, il tape rm .zshrc. Aïe. Coup dur.

À ce moment-là, mon collègue est un peu dégoûté - je l’aurais été aussi. Avec rm, ça ne part pas à la corbeille, on ne récupère pas facilement ce que l’on a supprimé. Ça l’embête parce qu’il avait effectué plusieurs configurations dedans, et qu’il avait passé une heure avec la DSI pour optimiser le temps de chargement. Hop hop hop, attends. Quoi ?!

Lui aussi avait son terminal qui était long au lancement, et de mémoire, ça venait en partie de l’initialisation de nvm. Me voilà avec une piste intéressante. Je l’ai gardée dans un coin de tête, jusqu’à hier soir où j’ai fouillé les internets avec une idée de direction plus précise.

Mesurer le temps

À l’aide de deux instructions, on peut obtenir un rapport avec les différentes étapes exécutées au lancement de zsh et le temps associé.

Il suffit de modifier le fichier .zshrc pour y ajouter zmodload zsh/zprof au tout début, à la première ligne. On quitte le terminal, on le relance et on tape la commande zprof.

num  calls                time                       self            name
-----------------------------------------------------------------------------------
 1)    2        3047,39  1523,69   43,08%   2046,60  1023,30   28,93%  nvm
 2)    1        4998,69  4998,69   70,66%   1951,31  1951,31   27,58%  nvm_auto
 3)    1         821,18   821,18   11,61%    665,29   665,29    9,40%  nvm_ensure_version_installed
 4)    1         563,64   563,64    7,97%    563,64   563,64    7,97%  is_update_available
 5)    1         743,74   743,74   10,51%    180,11   180,11    2,55%  /.oh-my-zsh/tools/check_for_upgrade.sh
 6)    1         176,44   176,44    2,49%    174,59   174,59    2,47%  nvm_die_on_prefix
 7)    1         155,88   155,88    2,20%    155,88   155,88    2,20%  nvm_is_version_installed
 8)    1          93,04    93,04    1,32%     51,05    51,05    0,72%  compinit

Dans ce tableau, on retrouve le nom des étapes, le temps, le pourcentage du temps par rapport à l’ensemble, et c’est même classé dans l’ordre du plus long au plus rapide.

Sur ma machine, je vois clairement que nvm est dans le haut du panier. Plusieurs noms d’étapes semblent liées à nvm et elles prennent énormément de temps. Je vais donc optimiser le lancement de nvm, le reste me semble anecdotique. Je le ferais ou pas un jour. Sûrement jamais. :)

Améliorer l’initialisation de nvm

J’ai trouvé plusieurs moyens pour pallier la lenteur de nvm.

Supprimer nvm du .zshrc

Quand on installe nvm, il y a des instructions à ajouter dans notre configuration .zshrc. Leurs rôles sont de charger nvm, de s’assurer qu’il est à jour, de préparer l’auto-complétion, etc. C’est ce qui ralentit le lancement de notre terminal. Ces instructions ressemblent à ça :

export NVM_DIR="$HOME/.nvm"
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

Bon. Eh bien de manière pragmatique, on peut supprimer ces instructions de notre configuration .zshrc et le temps de lancement sera grandement amélioré. Si on n’utilise plus nvm, node et compagnie, ou très peu souvent, on n’a pas envie de pourrir l’expérience nominale de notre terminal.

Lazy loading de nvm

Une autre solution serait d’initialiser nvm uniquement lorsque l’on en a besoin. Quand on tapera une commande avec nvm, node ou npm par exemple. C’est du lazy loading. Ce serait l’idéal si on veut conserver nvm et que l’on veut éviter de ralentir le lancement du terminal.

Il est possible de le faire soi-même en créant quelques fonctions bash comme l’explique cet article. On peut aussi utiliser le système de plugin de zsh. Luke en a créé un pour nvm : zsh-nvm. J’ai opté pour cette solution.

• La première étape est de supprimer les éventuelles instructions nvm de notre fichier .zshrc (cf. partie précédente).
• On installe ensuite le plugin zsh-nvm.
• On modifie le fichier .zshrc pour ajouter zsh-nvm dans la liste des plugins.
  • La ligne ressemble à plugins=(.......).
• On indique au plugin que l’on veut du lazy loading.
  • On ajoute export NVM_LAZY_LOAD=true juste avant la liste des plugins.
• On peut ajouter l’auto-complétion si nécessaire.
  • En ajoutant également export NVM_COMPLETION=true avant la liste des plugins.

Changer de version manager pour node

Vu que nvm est le fautif et qu’il existe d’autres version manager pour node, on peut se demander s’il en existe qui sont plus rapides.

Ça semble être le cas pour fnm (Fast Node Manager). Son nom est revenu plusieurs fois pendant mes recherches et dans les commentaires de personnes qui proposaient des alternatives au lazy loading de nvm. Je ne l’ai pas essayé.

Il y a également asdf, un outil unique qui propose de gérer les versions de multiples autres outils (node, Ruby, python, …). J’en parlais dans mon article sur les version manager. Il serait plus rapide que nvm d’après ce que j’ai lu. À tester. Je pense que je finirais par me passer de mes autres version manager pour tout regrouper avec asdf.

Quelques références de contenu que j’ai parcouru :

• https://dev.to/thraizz/fix-slow-zsh-startup-due-to-nvm-408k
• https://blog.mattclemente.com/2020/06/26/oh-my-zsh-slow-to-load/
• https://broken-by.me/lazy-load-nvm/
• https://stackoverflow.com/questions/47009776/how-to-run-nvm-in-oh-my-zsh

I am jealous of the experience Visual Studio offers with C# and the Live Unit Testing feature. Each line of the code is decorated with a symbol indicating if it is covered by passing tests or failing tests, in real-time. Awesome. I need something like that.

I started by searching a similar tool for the languages I use. Then I created a simple script, which runs a command after each file change. Finally, I found a really nice tool for file change monitoring. It is powerful, cross-platform, and open-source. And that’s what I want to talk to you about.

Watch my changes! 🔍

One way to improve the feedback given by our tests is to know immediately if a change breaks a test. To achieve this goal, we have to continually run tests. The more often we run the tests, the smaller the failing piece of code will be. Ideally, tests should be run after each change. But we can easily forget, or it can be cumbersome.

So we need a way to monitor files and automatically execute a command if there is a change. Some languages and tools offer a built-in way to do that. For example:

• Kotlin through Gradle > gradle test —-continuous
• Elm with elm-test > elm-test --watch

But what if the programming language and tool we are using do not have a watch option? This is where fswatch comes in.

fswatch 📡

Open-source and cross-platform, fswatch is a great tool to monitor file change. It provides recursive directory monitoring, filtering, and supports many OS-specific APIs such as kevent, inotify, and FSEvents.

By using these low-level APIs, fswatch is able to detect any changes in your specified paths and to send informations to another command. The tool is good enough to throttle the execution of the command: it will wait for the user to stop editing the code.

For more information about features or how to install it, please take a look at the GitHub repository.

https://github.com/emcrisostomo/fswatch

Usage

In most cases, you simply want to fire a command as soon as a change is detected in a folder. It’s as simple as this line:

fswatch -or YOUR_PATHS | xargs -n1 -I{} YOUR_COMMAND

fswatch accepts a list of paths to monitor. The o option asks the tool to group changes by batch, and the r option stands for watching subdirectories recursively. Events are then sent through xargs to your command. Here is an example for swift, observing one folder:

fswatch -or ./Project | xargs -n1 -I{} swift test

Note that fswatch will run until you stop it, by pressing Control + Z on macOS or Control + C on Linux for example. But that’s what we want, run indefinitely regardless of the test results.

Going further 🚀

So, you got the basics. Now we will see how to improve it.

Choose carefully the files to monitor

You may want to not run your tests for every kind of file changed. A change in an image or in a temp folder probably does not interest you. Observing the right files allows you to run tests only if an impacting change occurs. It can also prevent you from going into an infinite loop.

I had a case where build files were generated after each test, so that triggered the watch, and run tests again, and changes appear, and… this story will never end. The easiest solution for me was to specify multiple sub-directories as input to fswatch` instead of the whole project folder. Remember that you can set multiple paths.

fswatch -or ./Sources ./Tests | xargs -n1 -I{} swift test

The other way is to include or exclude paths matching a regex. According to the fswatch manual, you can set options like -i, --include and -e, --exclude for that.

Create a script

Sometimes, the command you want to fire for each change is long and requires a lot of parameters. It may even be composed of multiple commands. In that case, I recommend you to decompose this step and to create a script to run your tests.

fswatch -or ./Sources ./Tests | xargs -n1 -I{} run-tests.sh

Better, isn’t it? But we can still improve that. We can avoid typing that long line every time we start working. You see me coming, we’ll make a second script that will do it.

live-tests.sh

Keep it visible

Now that we have a real-time feedback, we want to see it. It would be a shame to have it hidden in the background. Good news, it is quite easy to keep a terminal in the foreground. Perhaps your favorite editor has already a panel with a terminal, and you just have to show it. Visual Studio Code, for instance.

Some editors like Sublime Text do not have a terminal panel by default, but you can add it with a plugin or extension. And if that’s not possible, you still have the option to put the terminal on a second screen, if you have one, or to reduce your editor window and put a terminal at the left, right, or bottom of it.

You have everything you need to get started. Monitoring files is at your hands. Enjoy the continuous and real-time feedback of your unit tests.

If you write Swift, Playgrounds are another way to speed up that feedback.