mise (prononcé "meez") est un outil de gestion d'environnements de développement écrit en Rust. Il réunit en un seul fichier ce que vous faisiez avant avec asdf, direnv, et un Makefile : versions d'outils, variables d'environnement, tâches automatisées, et alias shell.
Le problème que mise résout
Vous rejoignez un projet. Le README dit d'installer Node 18, Terraform 1.5 et Python 3.11. Votre collègue a Node 20, Terraform 1.9 et Python 3.12. Un troisième a tout installé via Homebrew et n'a aucune idée de ses versions.
Le pipeline CI échoue avec une erreur obscure. Après investigation : une incompatibilité de syntaxe entre votre version de Terraform et celle du CI. Deux heures de perdues.
Le Makefile du projet contient vingt cibles, mais la moitié ne fonctionne qu'avec certains outils installés globalement. Le .env n'est pas documenté. Les variables d'environnement sont éparpillées entre .bashrc, des exports manuels, et une wiki que personne ne lit.
Ce scénario est la norme dans la plupart des équipes de développement. mise le résout en un seul fichier : mise.toml.
Qu'est-ce que mise ?
mise est le successeur spirituel d'asdf, le gestionnaire de versions multi-langages très populaire dans l'écosystème DevOps. Là où asdf se contentait de gérer les versions d'outils, mise va beaucoup plus loin :
| Ce que vous faisiez avant |
Avec mise |
| asdf pour les versions d'outils |
✅ intégré |
| direnv pour les variables d'environnement |
✅ intégré |
| Makefile pour les tâches |
✅ intégré |
.env pour la config locale |
✅ intégré |
Alias dans .zshrc |
✅ intégré |
La philosophie est simple : le mise.toml est la source de vérité de l'environnement de développement, versionnée dans le repo, partagée par toute l'équipe.
Installation et premier pas
L'installation se fait en une ligne :
curl https://mise.run | sh
Puis on active mise dans son shell (.bashrc ou .zshrc) :
echo 'eval "$(mise activate bash)"' >> ~/.bashrc
# ou pour zsh :
echo 'eval "$(mise activate zsh)"' >> ~/.zshrc
Pour déclarer les outils d'un projet :
mise use node@22 python@3.13 terraform@1.11
Cela génère (ou met à jour) un fichier mise.toml dans le répertoire courant :
[tools]
node = "22"
python = "3.13"
terraform = "1.11"
Un simple mise install installe toutes les versions déclarées. Et mise active automatiquement les bonnes versions dès que vous entrez dans le répertoire — sans rien faire de plus.
Onboarder en 30 secondes
Voici ce qui se passe quand quelqu'un clone un projet qui utilise mise :
git clone git@gitlab.com:mon-projet.git
cd mon-projet
mise install # installe tous les outils dans leurs versions exactes
mise run # liste toutes les tâches disponibles
Cette dernière commande affiche quelque chose comme :
$ mise run
deploy Déploie l'infrastructure complète
destroy Détruit l'infrastructure
tests Lance tous les tests
docs Génère la documentation
ssh Se connecte en SSH à la workstation
Le mise.toml est aussi un README interactif. Le nouvel arrivant sait immédiatement ce qu'il peut faire, sans chercher dans une documentation qui date de 2022.
mise trust : la sécurité dès l'onboarding
Quand mise rencontre un nouveau mise.toml, il ne l'exécute pas aveuglément — il demande d'abord une confirmation explicite :
mise WARN ~/projets/mon-projet/mise.toml is not trusted.
Run `mise trust` to trust this directory.
C'est un mécanisme de sécurité : un mise.toml peut définir des hooks et des variables d'environnement qui s'exécutent automatiquement. Faire confiance implicitement à tout fichier récupéré depuis git serait risqué.
mise trust # fait confiance au répertoire courant
mise trust ~/projets/ # fait confiance à tous les projets dans ce dossier
Pour les projets de confiance permanents (vos propres repos), on peut ajouter un chemin global dans la config :
# ~/.config/mise/config.toml
[settings]
trusted_config_paths = ["~/projets"]
Le lockfile : reproductibilité garantie
Quand mise.toml déclare node = "22", cela installe la dernière 22.x.x disponible au moment de l'exécution — ce qui peut changer d'un mois à l'autre.
Pour garantir que tout le monde — et la CI — installe exactement la même version, mise peut générer un fichier mise.lock, avec la commande mise lock :
# @generated - this file is auto-generated by `mise lock`
[[tools.opentofu]]
version = "1.11.4"
backend = "aqua:opentofu/opentofu"
[tools.opentofu."platforms.linux-x64"]
checksum = "sha256:0d744081951095c3e54fd4f0af5c48491ec03116ab02f1ad5ca4ed60d3b60efd"
url = "https://github.com/opentofu/opentofu/releases/download/v1.11.4/tofu_1.11.4_linux_amd64.tar.gz"
[tools.opentofu."platforms.macos-arm64"]
checksum = "sha256:2e52b9baccf925a1516ae850112b6eddce35d96e9b59fa954d191d6e8ef3af5f"
url = "https://github.com/opentofu/opentofu/releases/download/v1.11.4/tofu_1.11.4_darwin_arm64.tar.gz"
Ce n'est pas juste une version épinglée — c'est une URL exacte + un checksum SHA256 par plateforme. Toute altération du binaire entre sa publication et son installation serait détectée. Certains outils vont encore plus loin avec un champ provenance :
[[tools.trivy]]
version = "0.69.3"
backend = "aqua:aquasecurity/trivy"
[tools.trivy."platforms.linux-x64"]
checksum = "sha256:1816b632dfe529869c740c0913e36bd1629cb7688bd5634f4a858c1d57c88b75"
url = "https://github.com/aquasecurity/trivy/releases/download/v0.69.3/trivy_0.69.3_Linux-64bit.tar.gz"
provenance = "cosign"
[[tools.uv]]
version = "0.9.26"
backend = "aqua:astral-sh/uv"
[tools.uv."platforms.linux-x64"]
checksum = "sha256:708b752876aeeb753257e1d55470569789e465684c1d3bc1760db26360b6c28b"
url = "https://github.com/astral-sh/uv/releases/download/0.9.26/uv-x86_64-unknown-linux-musl.tar.gz"
provenance = "github-attestations"
provenance = "cosign" signifie que mise vérifie la signature Cosign du binaire. provenance = "github-attestations" vérifie une attestation GitHub Actions qui prouve que le binaire a été produit par le pipeline CI officiel du projet — et non par un acteur tiers.
C'est l'équivalent de package-lock.json ou Pipfile.lock, mais pour vos outils système, avec des garanties cryptographiques que les gestionnaires de paquets classiques n'offrent pas. Une fois mise.lock commité, mise install est déterministe et vérifiable : même résultat aujourd'hui, dans six mois, sur n'importe quelle machine.
Configuration globale : les outils du quotidien
Certains outils ne sont pas spécifiques à un projet — ils doivent être disponibles partout : jq, fzf, gh, bat, ripgrep...
Plutôt que de les installer via Homebrew ou votre gestionnaire de paquets système, mise propose une configuration globale dans ~/.config/mise/config.toml :
# ~/.config/mise/config.toml
[tools]
jq = "latest"
fzf = "latest"
gh = "latest"
bat = "latest"
ripgrep = "latest"
Ces outils sont disponibles dans tous vos terminaux, indépendamment des projets. Et avec mise upgrade, ils se mettent à jour en une commande.
La distinction est claire : global = outils transversaux, local = outils projet. mise ls vous montre à tout moment ce qui est actif et d'où ça vient.
Les tâches : le vrai différenciateur face à asdf
C'est ici que mise dépasse largement asdf. Un fichier mise.toml peut déclarer des tâches directement exécutables via mise run <tâche> — l'équivalent d'un Makefile, mais avec des fonctionnalités modernes : descriptions, dépendances, répertoire de travail, outputs.
Exemple générique :
[tasks.lint]
description = "Vérifie le style du code Python"
run = "ruff check ."
[tasks.test]
description = "Lance les tests unitaires"
depends = ["lint"] # lint s'exécute d'abord
run = "pytest tests/"
[tasks.ci]
description = "Pipeline complète : lint + tests"
depends = ["test"]
Exemple réel — chaîne de déploiement complète :
# mise.toml d'une plateforme de formation cloud
[tasks.deploy]
description = "Déploie l'infrastructure complète"
run = [
{ task = "terraform:deploy" },
{ task = "slides:build" },
{ task = "ansible:deploy" },
]
Une seule commande mise run deploy enchaîne : provisioning de l'infrastructure AWS avec OpenTofu, génération des supports de cours, et déploiement Ansible sur les machines. Chaque sous-tâche déclare son propre répertoire de travail et ses dépendances — plus de cd ci/terraform && tofu apply dans des scripts fragiles.
[tasks."terraform:deploy"]
alias = "terraform:apply"
description = "Applique les changements Terraform"
dir = "ci/terraform"
depends = ["terraform:init"]
run = ["tofu apply -auto-approve"]
Exécution parallèle et arguments
Plusieurs tâches peuvent s'exécuter en parallèle en les passant sur la même ligne :
mise run lint test build # lint, test et build tournent simultanément
Pour passer des arguments bruts à une tâche :
mise run build -- --release # args passés à build
mise run build -- --release ::: test -- --verbose # args séparés par tâche
Arguments typés avec usage
Pour aller plus loin, le champ usage permet de déclarer des arguments et des flags avec types, valeurs par défaut, choix possibles et aide auto-générée — comme une vraie CLI :
[tasks.deploy]
description = "Déploie l'application"
usage = '''
arg "<environment>" help="Environnement cible" {
choices "dev" "staging" "prod"
}
flag "-v --verbose" help="Mode verbeux"
flag "--region <region>" help="Région AWS" default="eu-west-1" env="AWS_REGION"
'''
run = '''
echo "Déploiement sur \({usage_environment?} (\){usage_region?})"
[[ "${usage_verbose?}" == "true" ]] && set -x
./deploy.sh "\({usage_environment?}" "\){usage_region?}"
'''
Les arguments deviennent automatiquement des variables d'environnement préfixées usage_ — pas de parsing manuel. Et mise génère un --help complet :
$ mise run deploy --help
Déploie l'application
Usage: deploy <environment> [OPTIONS]
Arguments:
<environment> Environnement cible [possible values: dev, staging, prod]
Options:
-v, --verbose Mode verbeux
--region <region> Région AWS [env: AWS_REGION] [default: eu-west-1]
-h, --help Print help
C'est la différence entre une tâche jetable et une tâche qui peut être utilisée par toute l'équipe sans lire son code source.
Mode watch
mise watch relance automatiquement une tâche quand ses fichiers sources changent — idéal pour le développement actif :
mise watch build # rebuild dès qu'un fichier source est modifié
Combiné avec la déclaration sources dans la tâche, mise sait exactement quels fichiers surveiller :
[tasks.build]
run = "cargo build"
sources = ["src/**/*.rs", "Cargo.toml"]
outputs = ["target/debug/myapp"]
Cerise sur le gâteau : si outputs est plus récent que sources, la tâche est ignorée automatiquement — comportement similaire à Make, sans la syntaxe archaïque.
Tâches en Python ou Node.js
Les tâches ne sont pas limitées au shell. N'importe quel interpréteur peut être utilisé via un shebang :
[tools]
python = "3.13"
[tasks.migrate]
description = "Exécute les migrations de base de données"
run = '''
#!/usr/bin/env python
import subprocess
result = subprocess.run(["python", "manage.py", "migrate"])
print("Migrations terminées !")
'''
mise utilise l'interpréteur déclaré dans [tools] — la tâche Python s'exécute avec la version de Python que mise gère, pas celle du système.
Générer la documentation des tâches
Puisque chaque tâche porte une description, mise peut en générer automatiquement une documentation Markdown :
mise gen task-docs
Le résultat est un tableau avec le nom, la description, les dépendances et les sources de chaque tâche — prêt à intégrer dans un wiki ou un README. Plus besoin de maintenir manuellement la liste des commandes disponibles : elle se dérive directement du mise.toml.
Variables d'environnement et multi-environnements
Fini le .env copié-collé entre les devs. Les variables d'environnement se déclarent directement dans mise.toml :
[env]
ANSIBLE_HOST_KEY_CHECKING = "false"
DAY = "{{ exec(command='date +%d') }}" # valeur dynamique !
MONTH = "{{ exec(command='date +%m') }}"
YEAR = "{{ exec(command='date +%Y') }}"
La syntaxe exec() permet des variables dynamiques calculées à l'exécution. Ici, DAY, MONTH et YEAR sont recalculés à chaque ouverture de terminal — pratique pour générer des noms de ressources cloud datés.
Charger un fichier .env existant
Si vous avez déjà un .env, mise peut l'inclure directement sans migration :
[env]
_.file = ".env"
DATABASE_URL = { required = true } # déclarée dans .env, vérifiée par mise
La syntaxe _.file charge le fichier .env avant d'appliquer les autres variables — ce qui permet de combiner les deux approches pendant une migration progressive.
Variables requises
mise peut marquer certaines variables comme obligatoires. Si la variable n'est pas définie, mise refuse de s'exécuter et affiche un message d'erreur explicite — plus de silences étranges quand quelqu'un oublie de configurer une clé d'API :
[env]
DATABASE_URL = { required = true }
API_KEY = { required = true }
Encore mieux : vous pouvez intégrer un message d'aide dans l'erreur pour guider le développeur :
[env]
DATABASE_URL = {
required = "Définissez DATABASE_URL avec votre chaîne de connexion PostgreSQL (ex: postgres://user:pass@localhost/dbname)"
}
AWS_ACCESS_KEY_ID = {
required = "Voir le wiki interne : Configuration des credentials AWS pour le développement local"
}
Le pattern habituel est de déclarer ces variables comme required dans mise.toml (commité), et de les définir dans mise.local.toml (ignoré par git) sur chaque poste développeur. C'est l'équivalent du .env.example + .env, mais avec validation intégrée et messages d'erreur utiles.
Multi-environnements
mise supporte nativement plusieurs fichiers d'environnement qui se surchargent :
mise.toml — base commune à toute l'équipemise.development.toml — outils et config spécifiques au dev localmise.production.toml — surcharges pour la CI/CD
# mise.production.toml — même tâche, output JUnit pour GitLab CI
[tasks."terraform:tflint"]
run = ["tflint --init", "tflint --format junit | tee tflint.junit.xml"]
On sélectionne l'environnement avec la variable MISE_ENV :
MISE_ENV=production mise run terraform:tflint
En CI, le pipeline définit simplement MISE_ENV: production — les tâches s'adaptent automatiquement. La parité local/CI est totale : les développeurs et le pipeline exécutent les mêmes commandes, avec les mêmes outils, aux mêmes versions.
Gestion des secrets
Variables d'environnement et secrets, c'est presque la même chose — sauf qu'un secret ne doit pas traîner en clair dans un repo git. mise documente plusieurs approches pour ça, avec des niveaux de maturité différents.
fnox (recommandé)
fnox est le compagnon naturel de mise pour les secrets — pas étonnant, c'est le même auteur (@jdx). Ce n'est pas une intégration directe : fnox fonctionne de manière indépendante, avec son propre fichier fnox.toml, et se charge de rendre les secrets disponibles comme variables d'environnement.
Le principe : fnox.toml vit dans le repo git, mais les secrets y sont soit chiffrés (le chiffré est committé, la clé ne l'est pas), soit des références vers un gestionnaire externe (1Password, AWS Secrets Manager, Vault, etc.) :
# fnox.toml
[providers]
age = { type = "age", recipients = ["age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p"] }
[secrets]
DATABASE_URL = { provider = "age", value = "YWdlLWVuY3J5cHRpb24uLi4=" } # chiffré, safe à committer
API_KEY = { default = "dev-key-12345" } # valeur en clair pour le dev local uniquement
L'intégration shell se configure une fois dans le profil :
eval "$(fnox activate bash)" # ou zsh, fish
Dès lors, entrer dans un répertoire avec un fnox.toml charge automatiquement les secrets comme variables d'environnement — exactement le même modèle que mise avec mise.toml. Les deux s'utilisent côte à côte sans friction.
fnox supporte une large gamme de providers : age, AWS KMS/Secrets Manager, Azure Key Vault, GCP KMS/Secret Manager, 1Password, Bitwarden, Infisical, HashiCorp Vault, et même le trousseau OS.
Les approches expérimentales de mise
Pour les cas plus simples, mise propose deux options directement dans mise.toml, toutes deux encore marquées expérimentales :
- sops — chiffre un fichier entier, chargé ensuite via
_.file
- age — chiffre des variables individuelles inline dans
[env]
Ces options sont pratiques pour des projets sans gestionnaire de secrets dédié, mais restez prudents : elles sont encore jeunes et l'interface peut évoluer.
Alias shell : partiellement remplacer .zshrc
Une fonctionnalité peu connue : mise peut gérer des alias shell directement dans mise.toml, via la section [shell_alias].
# ~/.config/mise/config.toml — alias globaux
[shell_alias]
k = "kubectl"
tf = "terraform"
ll = "ls -la"
# mise.toml — alias scoped au projet
[shell_alias]
tfa = "tofu apply -auto-approve"
tfi = "tofu init"
tfp = "tofu plan"
tma = "terramate script run apply"
tmg = "terramate generate"
tml = "terramate script run lint"
tmp = "terramate script run plan"
L'avantage décisif sur les alias dans .zshrc : ils sont scoped au répertoire du projet. tfa n'existe que quand vous êtes dans ce projet. Plus de conflits entre les alias de différents projets, et les alias font partie du repo — un nouveau dev les récupère automatiquement.
Note : les shell_alias nécessitent experimental = true dans [settings] de votre mise.toml.
Hooks : automatiser ce qu'on oublie
Les hooks s'exécutent automatiquement quand vous entrez dans un répertoire géré par mise :
# mise.development.toml
[hooks]
enter = '''
pre-commit install
uv sync --active
'''
Résultat : quand un développeur clone le projet et fait cd mon-projet, les hooks git pre-commit sont installés et les dépendances Python synchronisées — sans qu'il ait eu à lire quoi que ce soit. Les oublis d'initialisation n'existent plus.
Note : les hooks nécessitent experimental = true dans [settings] de votre mise.toml.
Mise à jour des outils et compatibilité Renovate
Mettre à jour les outils est trivial :
mise outdated # liste les outils avec des mises à jour disponibles
mise upgrade # installe les versions plus récentes (sans changer mise.toml)
mise upgrade --bump # met à jour ET bumpe la contrainte dans mise.toml
mise upgrade node # met à jour un outil spécifique
La nuance entre upgrade et upgrade --bump est importante : upgrade seul installe une version plus récente localement mais laisse mise.toml intact — les autres développeurs ne bénéficient pas de la mise à jour. --bump met aussi à jour mise.toml, ce qui propage le changement à l'équipe via git.
Renovation automatique avec Renovate
Renovate comprend nativement le format mise.toml. Avec une configuration minimale, il ouvre automatiquement des merge requests quand une nouvelle version d'un outil est disponible :
{
"extends": ["config:recommended"],
"packageRules": [
{
"matchManagers": ["mise"],
"automerge": true
}
]
}
Combiné avec Renovate, mise.toml devient un inventaire d'outils qui se maintient quasiment tout seul : Renovate détecte les nouvelles versions, ouvre une MR, les tests CI valident, et la MR est mergée automatiquement si tout passe.
L'écosystème : backends, plugins, et limites
Un backend est le mécanisme par lequel mise télécharge et installe un outil : il détermine la source du binaire, le format d'installation, et les vérifications de sécurité appliquées. Chaque outil dans mise.toml est servi par un backend — aqua, cargo, npm, ubi, etc.
Le registre officiel de mise couvre un peu plus de 1000 outils, avec un fort accent DevOps (héritage direct d'asdf) : terraform, kubectl, helm, aws-cli, k9s, kind, kustomize, helmfile...
Petit bémol : la couverture des outils plus orientés "développement" (frameworks spécifiques, outils de niche) est moins bonne. asdf dispose parfois de plugins communautaires que mise n'a pas encore intégrés. Ça s'améliore vite, mais c'est un point à vérifier avant de choisir mise sur un projet avec une toolchain inhabituelle.
Le backend aqua : sécurité intégrée
Aqua est le backend recommandé pour la grande majorité des outils CLI. Il se distingue fondamentalement des plugins asdf par son modèle de sécurité :
| Aspect |
Plugins asdf |
Backend aqua |
| Format |
Scripts shell |
YAML déclaratif |
| Exécution de code arbitraire |
Oui |
Non |
| Vérification des checksums |
Rare |
Systématique |
| Signatures cryptographiques |
Non |
Cosign, SLSA, minisign |
| Maintenance |
Fragmentée (1 repo/plugin) |
Centralisée |
Concrètement, le niveau de vérification dépend de ce que le projet publie. Le fichier mise.lock le rend explicite via le champ provenance :
- Pas de
provenance → vérification du checksum SHA256 uniquement (ex: opentofu, tflint)
provenance = "cosign" → checksum + signature Cosign vérifiée (ex: trivy)provenance = "github-attestations" → checksum + attestation GitHub Actions (ex: uv)
La plupart des projets publient au minimum des checksums — c'est déjà un sacré progrès par rapport à curl | sh ou à un plugin asdf qui télécharge sans rien vérifier.
Il y a quand même un point noir au tableau : aqua possède son propre registre de plus de 2200 outils, mais mise n'en intègre qu'une partie dans son binaire. Autrement dit, ce n'est pas parce qu'un outil existe chez aqua qu'on peut l'installer directement depuis mise — il faut qu'il ait été explicitement référencé. En pratique, le registre de mise tourne autour du millier d'outils, donc les outils courants du monde DevOps sont bien couverts, mais on ne peut pas exploiter l'étendue du registre aqua.
Pour voir exactement ce que votre version de mise expose via aqua :
mise doctor 2>&1 | grep "baked in"
# aqua:
# baked in registry tools: 2201 # à l'heure de cet article
Pour les outils absents, les autres backends viennent à la rescousse :
[tools]
"ubi:cli/cli" = "latest" # binaire depuis les GitHub Releases
"cargo:ripgrep" = "14" # depuis crates.io
"go:golangci-lint" = "1.64" # depuis go modules
"npm:prettier" = "latest" # depuis npm
"pypi:httpie" = "latest" # depuis PyPI
Le backend ubi est particulièrement pratique : il installe n'importe quel binaire publié dans les GitHub Releases d'un repo. Attention cependant — sans vérification cryptographique, contrairement à aqua. C'est un bon filet de sécurité pour les outils qui ne sont pas encore dans le registre de mise, mais ça ne remplace pas les garanties qu'aqua apporte.
Autres points forts de l'écosystème :
- Compatibilité asdf : les plugins asdf existants fonctionnent dans mise, facilitant la migration
- PATH plutôt que shims : mise est nettement plus rapide qu'asdf sur les temps de démarrage shell
- Intégrations IDE : VS Code, IntelliJ, Zed détectent automatiquement les environments mise
Comparaison : mise vs asdf vs devbox vs devcontainer
| Critère |
mise |
asdf |
devbox |
devcontainer |
| Gestion versions d'outils |
✅ |
✅ |
✅ |
✅ |
| Task runner intégré |
✅ |
❌ |
❌ |
❌ |
| Variables d'environnement |
✅ |
❌ |
partiel |
via Dockerfile |
| Config globale |
✅ |
✅ |
✅ |
❌ |
| Multi-environnements |
✅ |
❌ |
❌ |
par image |
| Alias shell scoped |
✅ |
❌ |
❌ |
❌ |
| Lockfile |
✅ |
❌ |
✅ |
par image |
| Compatibilité Renovate |
✅ |
❌ |
partiel |
❌ |
| Isolation complète (container) |
❌ |
❌ |
✅ |
✅ |
| Vitesse d'installation |
⚡ Rust |
Lent (bash) |
Lent (nix) |
Long (image) |
| Courbe d'apprentissage |
Faible |
Faible |
Nix requis |
Docker requis |
Quand choisir quoi :
- mise → le cas général. Projet d'équipe avec toolchain hétérogène, besoin d'un task runner et d'environnements reproductibles. C'est le point de départ par défaut.
- asdf → si vous avez un écosystème asdf déjà en place et aucun besoin de tâches ou de variables d'environnement. La migration vers mise est douce : les fichiers
.tool-versions sont compatibles.
- devbox → si vous voulez une isolation Nix à 100%, avec des environnements parfaitement reproductibles au niveau des dépendances système. Courbe d'apprentissage plus élevée.
- devcontainer → si l'isolation container complète est requise (postes Windows, politique de sécurité stricte, environnements hautement hétérogènes).
Ces outils ne s'excluent pas forcément : il est courant d'utiliser mise pour les outils et les tâches, avec un devcontainer pour les développeurs sur Windows. Et pour passer de l'un à l'autre, mise a une commande toute faite :
mise gen devcontainer
Elle génère un devcontainer.json à partir du mise.toml existant — les outils déclarés dans [tools] sont automatiquement reportés dans la configuration du container. C'est une bonne façon d'offrir les deux options en parallèle sans maintenir deux configurations distinctes à la main.
Diagnostics
En cas de comportement inattendu, mise doctor est la première commande à lancer :
mise doctor
# version: 2026.1.7 linux-x64
# activated: yes
# shims_on_path: no
# ...
# ✓ No problems found
Elle vérifie l'installation, l'activation du shell, la présence de conflits, et liste les backends disponibles. Utile aussi pour s'assurer que l'intégration IDE est bien détectée.
Conclusion
mise.toml est une déclaration d'intention : voici les outils, leurs versions, comment lancer le projet, et quelle config d'environnement est nécessaire. C'est la documentation exécutable que les README ont toujours voulu être.
Pour adopter mise sur un projet existant, pas besoin de tout migrer d'un coup. Commencez par un outil :
mise use node@22
Le fichier mise.toml est créé, vous et vos collègues avez la même version de Node. Ajoutez une tâche la semaine suivante. Puis les variables d'environnement. La migration est progressive, et chaque étape apporte de la valeur immédiatement.
La documentation officielle est disponible sur mise.jdx.dev. Le registre des outils supportés : mise.jdx.dev/registry.
