Fondamentaux¶

Comprendre pourquoi gérer plusieurs versions de runtimes est essentiel et comment les outils modernes résolvent ce problème.

Le problème des versions multiples¶

Un développeur travaille souvent sur plusieurs projets simultanément :

Sans outil de gestion, les conflits sont inevitables :

• node --version retourne une seule version pour tout le système
• Mettre a jour Node pour un projet casse l'autre
• Les dependances natives compilees contre une version ne fonctionnent pas avec une autre

L'approche : isolation par projet¶

La solution est de lier une version de chaque runtime a un projet :

projet-a/
├── .tool-versions ← node 20.11.0, python 3.12.1
└── src/

projet-b/
├── .tool-versions ← node 18.19.0, python 3.9.18
└── src/

Quand vous entrez dans projet-a/, node --version retourne 20.11.0. Quand vous entrez dans projet-b/, il retourne 18.19.0. Automatiquement.

Le fichier .tool-versions¶

Format standard cree par asdf et repris par mise :

# .tool-versions
node 20.11.0
python 3.12.1
golang 1.22.0

Chaque ligne : <outil> <version>. Le fichier est commite dans Git — toute l'équipe utilise les mêmes versions.

Le fichier mise.toml¶

Format alternatif propre a mise, plus expressif :

# mise.toml
[tools]
node = "20.11.0"
python = "3.12.1"
golang = "1.22.0"

[env]
DATABASE_URL = "postgres://localhost:5432/mydb"

Les deux formats sont supportes par mise. .tool-versions est plus portable (compatible asdf), mise.toml offre plus de fonctionnalités.

Relation avec les gestionnaires natifs¶

Les gestionnaires natifs (nvm, pyenv) fonctionnent bien pour un seul langage. Dès que vous travaillez avec 2+ langages, un outil unifie (mise ou asdf) simplifie la gestion.

Concepts cles¶