Cas avances¶

Tâches mise, variables d'environnement par projet, creation de plugins custom et integration avec les devcontainers.

Tâches mise (task runner)¶

mise peut remplacer Make, npm scripts ou just comme task runner :

# mise.toml
[tasks.dev]
run = "npm run dev"
description = "Lancer le serveur de developpement"

[tasks.test]
run = "pytest -v --cov"
description = "Lancer les tests avec couverture"

[tasks.lint]
run = ["ruff check .", "npm run lint"]
description = "Lancer tous les linters"

[tasks.build]
run = "docker build -t myapp ."
depends = ["test", "lint"]
description = "Build apres validation"

[tasks.clean]
run = "rm -rf dist/ build/ __pycache__/ node_modules/.cache"
description = "Nettoyer les artefacts"

# Executer une tache
mise run dev
mise run test
mise run build  # Execute test et lint d'abord (depends)

# Lister les taches disponibles
mise tasks
# dev    Lancer le serveur de developpement
# test   Lancer les tests avec couverture
# lint   Lancer tous les linters
# build  Build apres validation
# clean  Nettoyer les artefacts

# Raccourci : mise run = mise r
mise r dev

Tâches avec arguments¶

[tasks.test]
run = "pytest"
# Les arguments supplementaires sont passes a la commande

# mise run test -- -v --cov -k "test_login"
# → pytest -v --cov -k "test_login"

Tâches en fichiers¶

Pour des tâches complexes, utiliser des fichiers :

mise-tasks/
├── deploy.sh
├── migrate.sh
└── seed.sh

# mise.toml
[tasks.deploy]
run = "bash mise-tasks/deploy.sh"
description = "Deployer l'application"

[tasks.migrate]
run = "bash mise-tasks/migrate.sh"
description = "Executer les migrations"

Variables d'environnement par projet¶

# mise.toml
[env]
NODE_ENV = "development"
DATABASE_URL = "postgres://localhost:5432/mydb"
REDIS_URL = "redis://localhost:6379"

# Variables derivees
API_URL = "http://localhost:{{env.PORT | default: 3000}}"

# Charger depuis un fichier .env
_.file = ".env.local"

# Verifier les variables
mise env
# DATABASE_URL=postgres://localhost:5432/mydb
# NODE_ENV=development
# ...

# Executer une commande avec l'environnement
mise exec -- env | grep DATABASE

Ne pas commiter les secrets

mise.toml est commite. Les secrets vont dans .env.local (dans .gitignore) et sont charges via _.file.

Creation de plugins custom¶

Pour un outil interne ou un outil non couvert par les plugins existants :

# Structure d'un plugin asdf-compatible
my-plugin/
├── bin/
│   ├── list-all         # Liste les versions disponibles
│   ├── download         # Telecharge une version
│   └── install          # Installe une version
└── lib/
    └── utils.bash       # Fonctions utilitaires

#!/bin/bash
# bin/list-all — doit afficher les versions une par ligne
curl -s https://api.github.com/repos/org/tool/releases \
  | jq -r '.[].tag_name' \
  | sed 's/^v//' \
  | sort -V

#!/bin/bash
# bin/install
set -e
local version=$ASDF_INSTALL_VERSION
local install_path=$ASDF_INSTALL_PATH

mkdir -p "$install_path/bin"
curl -L "https://github.com/org/tool/releases/download/v${version}/tool-linux-amd64" \
  -o "$install_path/bin/tool"
chmod +x "$install_path/bin/tool"

Installer le plugin :

mise plugins install my-tool /chemin/vers/my-plugin
mise use my-tool@1.0.0

Integration devcontainers¶

mise peut fonctionner dans un devcontainer. Deux approches :

Approche 1 : mise dans le devcontainer¶

// .devcontainer/devcontainer.json
{
  "postCreateCommand": "curl https://mise.run | sh && mise install",
  "remoteEnv": {
    "PATH": "${containerEnv:HOME}/.local/bin:${containerEnv:PATH}"
  }
}

Approche 2 : features devcontainer (préfère)¶

Utiliser les features devcontainer au lieu de mise dans le conteneur. Les features installent les runtimes directement :

{
  "features": {
    "ghcr.io/devcontainers/features/node:1": { "version": "20.11.0" },
    "ghcr.io/devcontainers/features/python:1": { "version": "3.12.1" }
  }
}

Quand utiliser mise dans un devcontainer ?

Utilisez les features pour la plupart des cas. Utilisez mise dans le devcontainer si vous avez besoin de ses fonctionnalités supplémentaires (tâches, env) ou si vous gerez des outils non couverts par les features.

Mise et CI/CD avance¶

Utiliser mise.toml comme source unique de vérité pour les versions ET les tâches :

# .github/workflows/ci.yml
jobs:
  test:
    steps:
      - uses: jdx/mise-action@v2
      - run: mise run test

  lint:
    steps:
      - uses: jdx/mise-action@v2
      - run: mise run lint

  build:
    needs: [test, lint]
    steps:
      - uses: jdx/mise-action@v2
      - run: mise run build

Le même mise run test est execute en local et en CI. Pas de divergence possible.