Mise : présentation de la fonctionnalité de tâches pour monorepo

 (github.com/jdx)
7 points par GN⁺ 2025-10-07 | 2 commentaires | Partager sur WhatsApp
  • mise annonce une nouvelle fonctionnalité de tâches pour monorepo
  • Elle fournit un espace de noms unifié pour les tâches, permettant de gérer facilement les environnements, outils et tâches de chaque projet dans des dépôts contenant de nombreux projets
  • Elle inclut diverses fonctionnalités comme des motifs génériques puissants, l’héritage des environnements/outils et un contexte d’exécution cohérent
  • Elle apporte simplicité et flexibilité aux monorepos utilisant plusieurs langages ou des environnements complexes
  • Par rapport à Bazel, Turborepo et autres, ses points forts sont l’indépendance vis-à-vis du langage, la facilité de configuration et la gestion unifiée

Introduction : annonce de la fonctionnalité de tâches pour monorepo

  • mise introduit une nouvelle fonctionnalité appelée Monorepo Tasks
  • Elle offre une prise en charge de premier plan des monorepos, permettant de conserver séparément et de gérer efficacement les outils, variables d’environnement et tâches de chaque projet dans un dépôt contenant plusieurs projets

Principales fonctionnalités

  • Espace de noms unifié pour les tâches : découverte automatique de toutes les tâches du monorepo, avec un préfixe basé sur leur emplacement pour les distinguer clairement
    Exemple :
    mise //projects/frontend:build
    mise //services/api:deploy
  • Héritage intelligent des outils et de l’environnement : les outils communs peuvent être définis à la racine, puis redéfinis au besoin dans les sous-projets
    • Exemple : les réglages node=20 et python=3.12 du mise.toml racine sont automatiquement hérités par tous les sous-projets
    • Un projet spécifique (mise.toml) peut les surcharger avec node=14, tout en continuant à hériter du réglage python du niveau supérieur
  • Motifs génériques puissants :
    • Exécuter les tests de tous les projets : mise //...:test
    • Exécuter tous les builds sous services/ : mise //services/...:build
    • Exécuter toutes les tâches dans frontend : mise '//projects/frontend:*'
    • Il est possible de lancer des groupes selon le nom des tâches
  • Exécution cohérente en toutes circonstances : quel que soit l’endroit depuis lequel une tâche est lancée, elle s’exécute avec l’environnement et les outils définis dans son config_root
  • Propagation automatique de la confiance : si seule la racine du monorepo est marquée comme approuvée (Trust), les configurations filles le deviennent automatiquement

Guide de démarrage rapide

  1. Définir experimental_monorepo_root=true dans le mise.toml racine
  2. Activer le drapeau expérimental (MISE_EXPERIMENTAL=1)
  3. Ajouter des tasks dans le mise.toml de chaque projet
    • Exemple :
      [tasks.build]
      run = "npm run build"
  4. Exécuter les tâches souhaitées depuis la racine ou n’importe quel chemin
    • mise //projects/frontend:build
    • mise //...:test

Exemple de structure de monorepo

  • myproject/
    ├── mise.toml (experimental_monorepo_root = true)
    ├── services/
    │ ├── api/mise.toml
    │ ├── worker/mise.toml
    │ └── scheduler/mise.toml
    └── apps/
    ├── web/mise.toml
    └── mobile/mise.toml
  • Exécuter le build de tous les services : mise //services/...:build
  • Tester toutes les apps : mise //apps/...:test
  • Exécuter toutes les tâches : mise '//...:*'

Contexte d’adoption et effets

  • Cette fonctionnalité part d’un constat sur la complexité de la gestion des monorepos et des scripts répétitifs
  • Définir une fois, exécuter partout : duplication minimale
  • Application automatique des bons outils/environnements pour chaque projet
  • Simplification des pipelines CI/CD grâce à des motifs génériques puissants
  • Amélioration de la navigation et de la compréhension via l’espace de noms des tâches

Comparaison avec les principaux outils existants

  • Simple Task Runners (Taskfile, Just, etc.)

    • Optimisés pour l’automatisation d’un projet unique, ils ne prennent pas en charge dans les monorepos l’espace de noms unifié, l’héritage ou les motifs génériques
    • mise propose la découverte automatique des tâches et une prise en charge avancée des motifs

  • Outils centrés JavaScript (Nx, Turborepo, Lerna)

    • Très puissants pour les monorepos JS/TS (graphe de dépendances, codegen, cache, etc.)
    • mise est agnostique vis-à-vis du langage, prend en charge divers langages/stacks et propose une gestion unifiée des outils et variables d’environnement

  • Systèmes de build à grande échelle (Bazel, Buck2)

    • Ils offrent un cache distribué, l’exécution distante, etc., mais présentent une forte complexité et une courbe d’apprentissage élevée, avec de nombreuses contraintes structurelles
    • mise adopte une approche non hermétique (non-hermetic), avec une configuration souple et une adoption facile

  • Autres (Rush, Moon, etc.)

    • Rush : orchestration de build dédiée à JS
    • Moon : basé sur Rust, orienté prise en charge multi-langage

Ce qui rend mise Monorepo Tasks particulier

Fonctionnalité Simple Runners Spécialistes JS Build Systems mise
Prise en charge multi-langage ✅ ❌ ✅ ✅
Facilité d’apprentissage ✅ ⚠️ ❌ ✅
Découverte unifiée des tâches ❌ ✅ ✅ ✅
Motifs génériques ❌ ⚠️ ✅ ✅
Gestion des versions d’outils ❌ ❌ ⚠️ ✅
Héritage d’environnement ❌ ⚠️ ❌ ✅
Configuration minimale ✅ ⚠️ ❌ ✅
Mise en cache des tâches ❌ ✅ ✅ ❌
  • Quand choisir Mise ?
    • Monorepo multi-langage
    • Gestion unifiée des outils et des tâches
    • Si vous privilégiez la simplicité
    • Convient aux utilisateurs déjà familiers avec mise
  • Quand envisager autre chose
    • Focalisation uniquement sur JS/TS → Nx, Turborepo
    • Très grands environnements enterprise (Google/Meta, etc.) → Bazel, Buck2
    • Besoin d’une mise en cache avancée des tâches → Nx, Turborepo, Bazel

Conclusion

  • La fonctionnalité de tâches pour monorepo de mise n’est pas limitée à un seul langage et a été conçue pour gérer facilement et de manière cohérente des monorepos complexes dans des environnements multi-langages
  • Grâce à une configuration minimale et à des motifs de tâches puissants, elle améliore à la fois la productivité et l’expérience des développeurs
  • Elle est bien plus simple et flexible que des solutions enterprise complexes

À lire aussi

2 commentaires

 
GN⁺ 2025-10-07
Avis Hacker News

  • Quand j’utilisais surtout Python auparavant, je ne voyais pas vraiment l’intérêt de Mise, je pensais que uv suffisait.
    Mais quand il faut aligner les versions par répertoire comme avec Node, et qu’on a besoin de points d’entrée communs comme mise build ou mise test quel que soit le langage ou le type de projet, on se rend compte de la vraie valeur de Mise.
    J’aime aussi beaucoup Just comme runner de tâches, et grâce à lui j’ai pu me détacher de Make.
    Make est puissant, mais l’expérience de développement m’a toujours laissé un peu sur ma faim.
    Just est peut-être plus puissant fonctionnellement que les tâches de Mise, mais pour moi Mise offre une combinaison idéale entre une fonction de tâches tout à fait correcte et une excellente gestion des outils.

    • En tant qu’amateur des Makefile simples, je suis curieux : quels avantages as-tu trouvés en passant de Make à Just puis à Mise ?

    • J’aimais vraiment just, mais configurer précisément l’environnement dans les tâches just était pénible, et charger un environnement virtuel aussi.
      C’est pour des raisons similaires que je suis passé à mise.

  • J’ai énormément d’attentes vis-à-vis de mise.
    C’est très vite devenu un outil incontournable à chaque nouveau projet.
    Pouvoir gérer plusieurs outils comme node, python, rust, go, etc. avec un seul fichier de configuration, tout en ayant un remplaçant simple à makefile, est extrêmement pratique.
    En général, je configure un hook postinstall, de sorte que quand quelqu’un récupère mon projet, il lui suffit d’exécuter mise install pour installer automatiquement les bonnes versions des outils ainsi que les paquets de dépendances.
    Là où nix me semble avoir une barrière à l’entrée élevée, mise est bien plus pragmatique.

    • Si l’approche Nix te paraît trop lourde, un outil comme devenv.sh améliore énormément l’accessibilité.
      Par exemple, avec languages.rust.enable = true, on peut configurer immédiatement un environnement de développement Rust.
      On peut aussi y ajouter des scripts, des tâches et des paquets.

    • Tu pourrais partager un exemple de configuration ?
      Ça a l’air intéressant.
      J’ai utilisé just et docker(-compose) dans un projet monorepo, et mes essais de moon & proto ont été brefs et plutôt décevants.
      J’aime la simplicité de just, mais l’onboarding de nouveaux membres sur plusieurs plateformes reste fastidieux.

    • J’ai moi aussi configuré un nouveau projet avec mise.
      C’est vraiment excellent, parce que les nouveaux arrivants peuvent démarrer bien plus facilement, sans étapes manuelles.

    • L’utilisation du hook postinstall dans mise m’intrigue.
      Tu y mets principalement quoi ?

  • L’absence de cache de tâches est une vraie déception.
    Quand des dépendances apparaissent dans le graphe des tâches, il faut pouvoir éviter de relancer celles qui ont déjà été effectuées et s’appuyer sur un cache, sinon les exécutions répétées perdent vite en efficacité, surtout dans un monorepo de taille intermédiaire.
    J’ai cherché si cette fonctionnalité était prévue, mais les issues du dépôt Mise étaient désactivées et le README n’en parle pas, ce qui ne m’inspire pas vraiment confiance.
    Si vous utilisez un monorepo npm mono-langage, je recommande Wireit.
    Wireit ajoute aux scripts npm des dépendances, un cache local et GitHub Actions, ainsi que des tâches de type service qui restent en exécution.
    Wireit GitHub

    • Mise prend aussi en charge un cache local de tâches, comme Make.
      Il suffit de définir sources et outputs ; voir le guide de configuration des tâches de mise.
      Même en ne définissant que sources, les changements de source sont suivis automatiquement.
      J’avais demandé cette fonctionnalité il y a longtemps pour accélérer les builds docker, et je l’utilise avec beaucoup d’efficacité.

    • Au contraire, le fait que mise se préoccupe moins du code source du projet ou des dépendances de bibliothèques fait partie de son attrait par sa simplicité.
      En général, il s’arrête volontairement à cette frontière fonctionnelle.

    • Le cache de tâches ne correspond pas vraiment à l’orientation de mise.
      Voir la documentation officielle sur les anti-objectifs.
      turbopack, moonrepo et d’autres se concentrent déjà sur ce problème.
      Il est probable que mise reste un runner de tâches léger, simplement centré sur l’exécution de scripts.

    • Je ne sais pas non plus pourquoi les issues du dépôt Mise sont désactivées.
      Avant, il y avait un ticket du type « le mainteneur préfère les discussions aux issues », mais il a disparu.
      J’ai lancé cette discussion à ce sujet.
      Après plusieurs années d’utilisation, j’ai personnellement une grande confiance dans ce projet et je le recommande autour de moi.
      Je conseille de regarder les discussions et les retours d’usage concrets.

    • C’est un peu comme demander à mise d’ajouter des fonctions de système de build à la bazel.
      On peut même considérer qu’il joue déjà un peu ce rôle.
      Le cache serait utile, mais il faut faire attention à la complexité supplémentaire que cela introduirait.
      Il vaudrait peut-être mieux réfléchir à une intégration avec des systèmes de build existants.

  • mise a l’air vraiment bien.
    Cela dit, en tant qu’utilisateur actuel de asdf, j’hésite un peu, parce que mise semble vouloir gérer beaucoup de choses de manière assez intrusive, notamment la manipulation du PATH.
    C’est vraiment pénible quand plusieurs outils modifient chacun le PATH différemment, donc j’ai fini par fixer moi-même le PATH dans .zprofile et supprimer tous les scripts d’initialisation divers.
    Si mise pouvait gérer à la fois les langages de programmation et les applications CLI installées via ces langages (cargo, go, uv, etc.), ce serait bien, mais c’est aussi le point qui pourrait rendre la migration un peu pénible.

    • Tu disais que la manipulation du PATH par ordre de priorité entre plusieurs outils était gênante, mais mise ne fonctionne pas comme ça.
      Si tu veux, tu peux utiliser des shims.
      Il prend en charge à la fois la gestion des outils propres à chaque langage et celle des langages eux-mêmes.

    • Je ne me souviens plus exactement pourquoi je suis passé de asdf à mise, mais après plusieurs années d’utilisation, je n’ai eu aucun problème.

  • Je trouve mise absolument excellent.
    C’est parfait pour les gens qui prennent au sérieux l’automatisation, la reproductibilité des environnements et le bootstrap rapide de nouveaux projets.
    En particulier dans les environnements Ruby/Python/Node, cela résout simplement les écarts de configuration entre machines et la reproduction répétée d’environnements, sans avoir besoin de Docker ou d’équivalents.
    Dans une petite équipe ou sur des projets personnels, on peut mettre en place facilement un environnement reproductible sans CI ni système de build (Bazel, Gradle, etc.).
    Je l’utilise aussi très bien avec chezmoi pour gérer les outils système en local.

  • Je suis récemment passé de just à mise.
    just est excellent lui aussi, mais il ne fournit qu’un rôle de runner de commandes, alors que j’avais besoin des fonctionnalités supplémentaires de mise.
    Je pense avoir bien fait de changer.
    Cela dit, j’aimerais que les cas d’usage, l’historique, les comparaisons avec d’autres outils (nix, docker, etc.) et les explications structurelles soient mieux présentés pour les débutants.
    J’aimerais voir une documentation plus claire sur le « pourquoi » de mise, avec des exemples montrant les différences concrètes et ce qui le distingue d’outils déjà existants.

  • Cette annonce m’enthousiasme vraiment.
    J’ai l’impression d’un bon mélange entre les avantages des runners de tâches simples comme just/taskfile et la puissance d’outils comme bazel/buck2.
    Je suis curieux de voir comment les autres vont l’utiliser, et j’attends avec intérêt les nouvelles expérimentations.

    • J’utilise moi aussi surtout mise et j’en suis presque entièrement satisfait.
      Mon workflow de gestion d’environnement a été énormément simplifié.
      En revanche, je n’ai pas vraiment besoin de la fonction de task runner.
      Make ou just remplissent déjà très bien ce rôle.
      Je ne l’ai pas vraiment essayé dans un monorepo, mais comme les deux outils prennent en charge l’import et l’extension de fichiers de tâches/recettes, je pense qu’on peut construire une configuration adaptée si nécessaire.
      L’UX ne sera peut-être pas aussi fluide qu’avec un outil sur mesure, mais je préfère que chaque outil reste concentré sur un seul rôle.
      mise intègre déjà beaucoup de choses dans son rôle de gestionnaire d’environnement, donc j’aimerais qu’il se concentre là-dessus.
      Au passage, je crois que mon interlocuteur est l’auteur de mise ; merci à lui.

  • Si vous voulez gérer les tâches d’un dépôt via un point d’entrée unique, vous pouvez jeter un œil à dela, que j’ai créé.
    Il scanne différentes définitions de fichiers de tâches comme pyproject.toml, package.json, makefile, etc., puis permet de lancer directement les tâches en CLI par leur nom.
    C’est très pratique, parce que je peux l’utiliser tel quel sur plusieurs dépôts sans amélioration particulière, et sans devoir modifier la structure du dépôt.
    Il ne prend pas encore en charge les tâches de mise, mais si la demande existe, je peux l’ajouter rapidement.
    D’après un relevé récent, mise est utilisé dans 94 des 100 000 dépôts GitHub les plus étoilés.
    Voir les données détaillées dans 2025 task runners census

    • Ça a l’air chouette ; est-ce que ça prend aussi en charge l’affichage de la liste complète des tâches ?
      Quand j’entre dans un dépôt de projet Node, la première chose que je fais est toujours npm run pour voir la liste des scripts.
      S’il y a un Makefile, je vais le lire, mais si toutes les cibles et dépendances sont cachées derrière des variables, je repars tout de suite.

  • Justement, je pensais récemment que ce serait bien que mise ait ce genre de fonctionnalité, donc je suis ravi de voir que c’est arrivé.
    Ce que j’ai le plus apprécié avec mise, c’est la possibilité d’installer des outils globaux côté backend via npm, go, cargo, etc.
    Par exemple, avec une commande simple comme mise use -g npm:prettier, on peut l’installer très facilement.
    Avant, quand j’utilisais nvm, je devais toujours me souvenir sur quelle version de node j’avais installé tel package global ; avec mise, c’est devenu beaucoup plus simple.
    J’ai toutefois eu récemment un petit bug : en essayant d’installer la toute dernière version de node, c’est l’avant-dernière qui s’est installée.

  • Si on peut utiliser un pure Nix-shell, mise peut sembler un peu moins séduisant.
    Cela dit, sa courbe d’apprentissage est bien plus faible que celle de Nix, donc il pourrait probablement se diffuser plus largement.

    • mise se distingue vraiment quand il s’agit de permettre à des personnes variées — pas seulement soi-même ou sa propre machine — de bootstrapper facilement un projet.
      Une configuration basée sur TOML est aussi très simple à comprendre pour la plupart des gens.
      Tout ce qui consistait autrefois à fouiller un README pour configurer l’environnement à la main, avec des méthodes d’installation différentes selon les langages, cesse d’être un problème avec mise.
      C’est particulièrement avantageux pour gérer des environnements Node/Ruby/Python.

    • J’ai utilisé nix-darwin pendant un an avant de finir par basculer sur mise.
      mise couvre 90 % de ce dont j’ai besoin avec seulement 1 % des contraintes.
      J’aime aussi les concepts de nix, et je pense clairement que l’avenir de la construction logicielle ira dans cette direction.
      Mais pour l’instant, je ne suis pas certain que ce soit nix qui en sera le principal moteur.