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.

Quand on est développeur, on utilise tout un tas d’outils et de SDK. Parfois sur plusieurs projets, qui utilisent des versions différentes bien évidemment. Je peux avoir besoin de Node.js 19 pour le front web et de Node.js 16 pour le backend. Je peux travailler à la fois sur une app Flutter en Dart 2 et une autre en Dart 3. J’ai peut-être besoin d’une version différente de Python sur mon poste et sur la CI.

Ou parfois sur le même projet avec des branches différentes. Je commence à migrer vers Dart 3 sur une branche, j’ai un bug de prod à corriger il faut que je retourne sur la branche principale qui elle est sous Dart 2.

Si on installe des versions spécifiques à la main, à quoi ressemble notre acrobatie ?

On désinstalle la version X. On télécharge et installe la version Y. On joue avec. On désinstalle la version Y. On télécharge et réinstalle la version X. À chaque étape, c’est un peu de temps perdu. Certains outils sont en plus lourds à télécharger et installer, on se retrouve vite à ouvrir son navigateur ou téléphone et sortir de notre flow :)

C’est là qu’interviennent les outils de gestion de versions.

Principe général

L’idée est simple. Plutôt que d’installer directement la toolchain d’un langage par exemple, on va installer l’outil de gestion de version dédié à tel ou tel langage. Chaque langage a son propre gestionnaire, et ce sont souvent des projets open-source. Ils se reconnaissent facilement à leur nom : ils sont souvent suffixés par Version Manager ou Version Management.

C’est ensuite via le Version Manager que l’on va installer la ou les versions du langage dont on a besoin. Les différentes versions seront installées dans un sous-dossier de l’outil et ne vont pas venir directement s’écraser entre elles dans le dossier /bin (comme ce pourrait être le cas avec une installation classique). On peut ainsi en avoir plusieurs téléchargées et installées sur un poste, directement prêtes à l’emploi.

Une fois qu’on a installé les versions qui nous intéressent, il n’y a plus qu’à indiquer la version par défaut via une simple commande. Et quand on veut changer ? Une commande et c’est opérationnel dans la même seconde. On jongle très facilement avec de multiples versions, branches, projets.

Switch automatique

Mieux encore. On peut aller un cran plus loin avec certains Version Manager : la version utilisée change automatiquement en fonction du projet que l’on ouvre. C’est le cas avec Ruby par exemple. Il suffit de créer un fichier .ruby-version, d’y écrire le numéro de la version (3.2.2), et de le placer dans le dossier racine du projet. Simple, basique.

L’outil de Version Manager détectera ce fichier et changera la version de Ruby utilisée de manière transparente et automatique. On jongle entre des projets et des branches sans aucune adhérence. On voit encore plus la puissance de ces outils ici.

L’intérêt de tels fichiers se retrouve aussi dans le travail en équipe. Le fichier est versionné au sein du projet, ce qui permet à tous les développeurs d’utiliser systématiquement les mêmes versions.

Quelques exemples

Vous en connaissez probablement déjà quelques uns, voire les utilisez. En voici quelques-uns que j’utilise :

• Si vous travaillez sur des projets web, vous jouez peut-être avec Node.js. Et si vous avez envie de jongler, allez voir du côté de nvm (Node Version Manager).
• Des applications mobiles avec Flutter ? fvm (Flutter Version Management) est là pour nous aider. Il gère aussi le langage Dart.
• chruby. Il en existe d’autres pour Ruby (rvm et rbenv), mais j’ai préféré celui-ci car il est léger et il bidouille moins le système (rvm et rbenv surchargent la commande cd par exemple).
• pyenv (Python Version Management).
• Rustup (Rust toolchain installer).

La question que vous vous posez peut-être maintenant, c’est est-ce qu’il en existe un seul pour les gouverner tous ? Jusqu’à maintenant, je n’avais pas connaissance d’un Version Manager qui gérait de multiples runtimes. Mais pendant l’écriture de cet article, j’ai effectué de rapides recherches et j’ai découvert des outils. C’est aussi pour ça que j’aime écrire, ça me permet de prendre du recul, de chercher davantage, de trouver de nouvelles choses.

En voici deux : asdf et rtx. Je n’ai fait aucun test pour le moment, mais je compte bien essayer et vous en parler à l’occasion. Si vous avez des retours d’expérience avec ces outils, ou d’autres, je suis preneur.

Contre-parties

Il peut y avoir un peu plus de configs et d’étapes à la première installation d’un Version Manager, versus installer directement le langage/SDK. Pour autant, cela reste relativement court et facile.

Autre effet de bord pour certains Version Manager, il faut parfois exécuter le langage/SDK via l’outil - ils agissent comme un proxy. Par exemple, on tapera la commande fvm flutter test au lieu de flutter test.

De mon point de vue, j’accepte pleinement ces deux points. Je trouve ces inconvénients largement acceptables et plus faibles que les avantages qu’ils apportent - je peux facilement jongler entre des versions, voire le rendre automatique entre mes projets et mes collègues.

Mais, il reste une question en suspens. Qui manage les versions des gestionnaires de versions ? 🙃

Une ouverture parfaite pour vous quitter. J’y réponds quand même avant de ranger ma plume. A priori, le besoin de jongler à ce niveau n’existe pas. Je les ai installés via Homebrew, le gestionnaire de paquet pour macOS, et c’est très bien ainsi.

C’était mon cas récemment. Je devais mettre à jour un référentiel dans l’application. On m’a expliqué la procédure habituelle (récupérer un gros fichier de données puis faire une multitude de modifications manuelles), et ça ne me donnait pas terriblement envie.

Faire le robot, en exécutant une série d’actions sans réfléchir, ne me motive pas trop. On n’a pas vraiment de valeur ajoutée. Par contre, faire un script qui le fera à ma place, ça c’était plaisant. Et j’ai même appris des choses au passage.

Automatisez

La mise à jour du référentiel se prêtait parfaitement à l’exercice. C’est une tâche simple — il faut télécharger un fichier, faire des traitements de données, et exporter. Et c’est une tâche récurrente — on nous demande régulièrement de le faire sur ce projet. Toutes les conditions sont réunies pour écrire un script.

J’ai sorti mon petit Python pour l’occasion. J’aime bien scripter avec ce langage, notamment lorsqu’il y a du traitement de données. Je trouve que le Python est adapté pour ce besoin, et il est très puissant. C’est aussi plus élégant et parfois plus simple qu’un script bash.

C’était ma préférence sur ce moment-là, mais on peut utiliser ce que l’on veut. Parfois j’utilise Python, parfois un script bash. Vous pouvez utiliser autre chose. Peu importe. Il faut juste faire attention à ne pas créer une usine à gaz, et à ce que ce soit très facilement utilisable.

Je trouve qu’il y a un petit côté créatif à écrire un script. On conçoit quelque chose plutôt que d’être un simple exécutant. On cherche comment automatiser. On réfléchit. On code. C’est au final plus proche de notre métier. On a de la valeur ajoutée.

La création du script m’aura pris un peu moins d’une heure. Ce temps passé est négligeable dans la vie du produit. Sachant que l’on doit régulièrement mettre à jour le référentiel, ce sera un grand gain de temps. En effet, cette tâche ne prend maintenant que quelques secondes. Il suffit de lancer le script. Tout est géré.

Et je peux même aller plus loin. Maintenant que le script est créé, on peut envisager d’automatiser à 100% la tâche. Plutôt que de prendre du temps à un développeur et même à un Product Owner (créer, tester et suivre un ticket), l’action pourrait être déclenchée automatiquement. À chaque merge ou release par exemple, avec l’aide de l’intégration continue.

Et appréciez

La productivité n’est pas le seul aspect positif. J’ai pris du plaisir à travailler sur ce sujet, en créant un script. Et j’ai même appris quelque chose. J’ai eu un problème de conversion de float en string. La manière dont Python tronquait par défaut ne convenait pas. J’ai découvert comment indiquer au parser le format que je souhaitais.

L’utilisation d’un script limite également les erreurs. Qui n’a jamais loupé un chercher / remplacer, ou oublié de modifier une ligne perdue au milieu de milliers d’autres ? Moi, ça m’est déjà arrivé. Lorsque l’on répète bêtement les mêmes actions des dizaines de fois, on peut facilement introduire une erreur. Le script ne se trompera pas, et on peut ajouter un filet de sécurité avec des tests unitaires.

Bref

Tous ces points positifs me font dire que la création d’un script est une idée intéressante dans ce genre de situation (une tâche récurrente, du traitement de données, une multitude d’actions à répéter, …).

Je ne dis pas qu’il faut y passer une semaine pour gagner quelques secondes, mais challengez l’idée, et essayez. Mettez-vous une timebox si vous avez peur d’y passer trop de temps. Commencez par quelque chose de simple.

Et vous, sur vos dernières itérations, quelles tâches pourriez-vous automatiser ? Qu’avez-vous déjà automatisé ?

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.