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

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.