Bonnes pratiques¶
Versioning, sécurité des plugins, fallback et compatibilité.
Versions exactes¶
Toujours utiliser des versions exactes dans .tool-versions pour les projets d'équipe :
# BON — reproductible
node 20.11.0
python 3.12.1
# MAUVAIS — non reproductible
node 20
python latest
Exception : le fichier global (~/.config/mise/config.toml) peut utiliser des versions majeures car c'est une configuration personnelle.
Mise à jour régulière¶
Vérifier les nouvelles versions régulièrement :
# Voir les mises a jour disponibles
mise outdated
# node 20.11.0 → 20.11.1
# python 3.12.1 → 3.12.2
# Mettre a jour (ecrit dans .tool-versions)
mise upgrade node
mise upgrade python
# Ou tout mettre a jour
mise upgrade
Mise à jour en PR dédiée
Mettez a jour les runtimes dans une Pull Request séparée, pas au milieu d'un feature branch. Cela facilite le bisect en cas de régression.
Sécurité des plugins¶
Les plugins asdf/mise telechargeant et exécutent du code. Precautions :
| Regle | Justification |
|---|---|
| Utiliser les plugins officiels quand possible | Maintenus et audites |
| Vérifier le code source avant d'installer un plugin tiers | Eviter les backdoors |
| Verrouiller les versions des plugins | Eviter les mises a jour surprises |
Utiliser mise trust pour chaque dépôt | Vérification humaine obligatoire |
# Verifier un plugin avant installation
# 1. Lire le code source sur GitHub
# 2. Verifier les etoiles, l'activite, les contributeurs
# 3. Installer
mise plugins install my-tool https://github.com/user/asdf-my-tool.git
Fallback global¶
Définir des versions globales pour ne jamais etre "sans runtime" :
La priorité est : local (.tool-versions) > parent (.tool-versions dans un répertoire parent) > global.
Compatibilité asdf¶
mise lit les fichiers .tool-versions d'asdf. La migration est transparente :
# Si l'equipe utilise deja asdf
# 1. Installer mise
# 2. Les .tool-versions existants fonctionnent tel quel
# 3. Migrer progressivement les postes
# mise lit aussi les fichiers specifiques
# .nvmrc → node
# .python-version → python
# .ruby-version → ruby
Ne pas melanger les gestionnaires¶
Eviter d'avoir mise ET nvm (ou pyenv) actifs en même temps :
# Verifier les conflits
which node
# Doit pointer vers ~/.local/share/mise/... pas vers ~/.nvm/...
# Si nvm est installe, le desactiver dans .zshrc
# Commenter ou supprimer les lignes NVM_DIR
.tool-versions dans .gitignore ?¶
Non. Le fichier doit etre commite. Il fait partie de la définition du projet au même titre que package.json ou pyproject.toml.
Ce qui ne doit PAS etre commite :