Mise: Einführung in die Monorepo-Task-Funktion

 (github.com/jdx)
7 Punkte von GN⁺ 2025-10-07 | 2 Kommentare | Auf WhatsApp teilen
  • mise hat eine neue Monorepo-Task-Funktion angekündigt
  • Sie bietet einen integrierten Task-Namespace, mit dem sich jeweilige Umgebungen, Tools und Tasks in vielen Projekten einfach verwalten lassen
  • Enthalten sind verschiedene Funktionen wie leistungsstarke Wildcard-Muster, Vererbung von Umgebungen/Tools und ein konsistenter Ausführungskontext
  • Für Monorepos mit verschiedenen Sprachen oder komplexen Umgebungen bietet sie Einfachheit und Flexibilität
  • Im Vergleich zu Bazel, Turborepo usw. liegen die Stärken in Sprachunabhängigkeit, einfacher Konfiguration und integrierter Verwaltung

Einführung: Ankündigung der Monorepo-Task-Funktion

  • mise führt mit Monorepo Tasks eine neue Funktion ein
  • Sie bietet erstklassige Monorepo-Unterstützung, mit der sich in Repositories mit vielen Projekten Tools, Umgebungsvariablen und Tasks pro Projekt unabhängig pflegen und effizient verwalten lassen

Hauptfunktionen

  • Integrierter Task-Namespace: Entdeckt automatisch alle Tasks im Monorepo und versieht sie je nach Speicherort mit Präfixen, um sie klar zu unterscheiden
    Beispiel:
    mise //projects/frontend:build
    mise //services/api:deploy
  • Intelligente Vererbung von Tools und Umgebungen: Gemeinsame Tools können im Root definiert und bei Bedarf in Unterprojekten überschrieben werden
    • Beispiel: Die Einstellungen node=20 und python=3.12 in der Root-mise.toml werden automatisch an alle Unterprojekte vererbt
    • In einem bestimmten Projekt (mise.toml) kann node=14 überschrieben werden, während die übergeordnete python-Einstellung weiter vererbt wird
  • Leistungsstarke Wildcard-Muster:
    • Tests in allen Projekten ausführen: mise //...:test
    • Alle Builds unter services/ ausführen: mise //services/...:build
    • Alle Tasks im frontend ausführen: mise '//projects/frontend:*'
    • Gruppenausführung ist auch nach Task-Namen möglich
  • Jederzeit konsistente Ausführung: Unabhängig davon, von wo aus ein Task gestartet wird, läuft er mit den Umgebungen und Tools, die im jeweiligen config_root definiert sind
  • Automatische Vertrauensweitergabe: Wenn nur der Monorepo-Root als Trust eingetragen wird, gelten untergeordnete Konfigurationen automatisch ebenfalls als vertrauenswürdig

Schnellstart-Anleitung

  1. In der Root-mise.toml experimental_monorepo_root=true setzen
  2. Das Experimental-Flag (MISE_EXPERIMENTAL=1) aktivieren
  3. In jeder mise.toml der Projekte Tasks hinzufügen
    • Beispiel:
      [tasks.build]
      run = "npm run build"
  4. Den gewünschten Task vom Root oder von einem beliebigen Pfad aus ausführen
    • mise //projects/frontend:build
    • mise //...:test

Beispielhafte Monorepo-Struktur

  • myproject/
    ├── mise.toml (experimental_monorepo_root = true)
    ├── services/
    │ ├── api/mise.toml
    │ ├── worker/mise.toml
    │ └── scheduler/mise.toml
    └── apps/
    ├── web/mise.toml
    └── mobile/mise.toml
  • Alle Services bauen: mise //services/...:build
  • Alle Apps testen: mise //apps/...:test
  • Alle Tasks: mise '//...:*'

Hintergrund und Wirkung

  • Ausgangspunkt waren die Komplexität der Monorepo-Verwaltung und wiederholte Skripte
  • Mit einmal definieren, überall ausführen wird Redundanz minimiert
  • Exakte Tools/Umgebungen werden automatisch pro Projekt angewendet
  • Leistungsstarke Wildcards vereinfachen CI/CD-Pipelines
  • Der Task-Namespace verbessert Auffindbarkeit und Verständlichkeit

Vergleich mit bestehenden wichtigen Tools

  • Einfache Task-Runner (Taskfile, Just usw.)

    • Für die Automatisierung einzelner Projekte optimiert; in Monorepos fehlt Unterstützung für integrierte Namespaces, Vererbung und Wildcards
    • mise bietet automatische Task-Erkennung und starke Musterunterstützung

  • JavaScript-zentrierte Tools (Nx, Turborepo, Lerna)

    • Stark in JS/TS-Monorepos (Dependency Graph, Codegen, Cache usw.)
    • mise ist sprachunabhängig, unterstützt unterschiedliche Sprachen/Stacks sowie integrierte Verwaltung von Tools und Umgebungsvariablen

  • Große Build-Systeme (Bazel, Buck2)

    • Bieten verteilten Cache, Remote Execution usw., haben aber eine hohe Komplexität und Lernkurve sowie viele strukturelle Einschränkungen
    • mise verfolgt einen non-hermetic-Ansatz und ermöglicht flexible Konfiguration sowie eine einfache Einführung

  • Sonstige (Rush, Moon usw.)

    • Rush: Build-Orchestrierung nur für JS
    • Moon: Rust-basiert, mit Ausrichtung auf Unterstützung mehrerer Sprachen

Das Besondere an mise Monorepo Tasks

Funktion Einfache Runner JS-spezialisiert Build-Systeme mise
Unterstützung mehrerer Sprachen ✅ ❌ ✅ ✅
Leicht zu erlernen ✅ ⚠️ ❌ ✅
Integrierte Task-Erkennung ❌ ✅ ✅ ✅
Wildcard-Muster ❌ ⚠️ ✅ ✅
Verwaltung von Tool-Versionen ❌ ❌ ⚠️ ✅
Umgebungsvererbung ❌ ⚠️ ❌ ✅
Minimale Konfiguration ✅ ⚠️ ❌ ✅
Task-Caching ❌ ✅ ✅ ❌
  • Wann sollte man Mise wählen?
    • Mehrsprachige Monorepos
    • Integrierte Verwaltung von Tools und Tasks
    • Wenn Einfachheit bevorzugt wird
    • Gut geeignet für Nutzer mit mise-Erfahrung
  • Wann man etwas anderes in Betracht ziehen sollte
    • Fokus nur auf JS/TS → Nx, Turborepo
    • Sehr große Enterprise-Umgebungen (Google/Meta usw.) → Bazel, Buck2
    • Bedarf an fortgeschrittenem Task-Caching → Nx, Turborepo, Bazel

Fazit

  • Die Monorepo-Task-Funktion von mise ist nicht auf eine einzelne Sprache beschränkt und wurde dafür entwickelt, komplexe Monorepos mit vielfältigen Sprachumgebungen einfach und konsistent zu verwalten
  • Mit minimaler Konfiguration und leistungsstarken Task-Mustern verbessert sie sowohl die Produktivität als auch die Developer Experience
  • Im Vergleich zu komplexen Enterprise-Lösungen ist sie deutlich schlanker und flexibler

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2025-10-07
Hacker-News-Kommentare

  • Als ich früher hauptsächlich Python verwendet habe, konnte ich den Reiz von Mise nicht so recht nachvollziehen und dachte, uv würde völlig ausreichen.
    Aber wenn man wie bei Node die Versionen pro Verzeichnis abstimmen muss und unabhängig von Sprache oder Projekttyp gemeinsame Entry-Points wie mise build oder mise test braucht, merkt man den wahren Wert von Mise.
    Ich mag auch Just als Task-Runner wirklich sehr und konnte dadurch von Make wegkommen.
    Make ist mächtig, aber beim Developer Experience hatte ich immer etwas auszusetzen.
    Just ist funktional möglicherweise stärker als die Task-Funktion von Mise, aber Mise kombiniert eine ziemlich gute Task-Funktion mit hervorragendem Tool-Management und ist für mich deshalb die beste Kombination.

    • Als Fan einfacher Makefiles würde mich interessieren, welche Vorteile der Wechsel von Make über Just hin zu Mise gebracht hat.

    • Ich mochte just wirklich sehr, aber bei just tasks war das korrekte Aufsetzen der Umgebung umständlich, und auch das Laden von virtuellen Umgebungen war lästig.
      Deshalb bin ich aus ähnlichen Gründen zu mise gewechselt.

  • Ich habe extrem hohe Erwartungen an mise.
    Es hat sich bei jedem neuen Projekt sehr schnell als unverzichtbares Tool etabliert.
    Es ist äußerst praktisch, mit nur einer Konfigurationsdatei Tool-Management für node, python, rust, go usw. sowie einen einfach nutzbaren Makefile-Ersatz auf einmal zu bekommen.
    In der Regel richte ich einen postinstall-Hook ein, sodass jemand, der mein Projekt übernimmt, nur mise install ausführen muss und automatisch die passenden Tool-Versionen sowie die abhängigen Pakete installiert bekommt.
    Im Vergleich zu nix, das für mich eine hohe Einstiegshürde hat, wirkt mise deutlich praxisnäher.

    • Wenn der Nix-Ansatz zu abschreckend wirkt, erhöhen Tools wie devenv.sh die Zugänglichkeit enorm.
      Zum Beispiel kann man mit languages.rust.enable = true sofort eine Rust-Entwicklungsumgebung aufsetzen.
      Zusätzlich lassen sich Skripte, Tasks und Pakete hinzufügen.

    • Könntest du ein Beispiel für deine Konfiguration teilen?
      Das klingt interessant.
      Ich habe in Monorepo-Projekten just und docker(-compose) verwendet, und meine kurzen Versuche mit moon & proto waren eher enttäuschend.
      Die Einfachheit von just gefällt mir, aber beim Onboarding neuer Teammitglieder auf verschiedenen Plattformen ist es immer noch umständlich.

    • Ich habe ebenfalls neue Projekte mit mise aufgesetzt.
      Es ist wirklich großartig, weil Neueinsteiger ohne manuelle Schritte deutlich leichter loslegen können.

    • Der Einsatz von postinstall-Hooks in mise klingt interessant.
      Mich würde interessieren, was du dort typischerweise einträgst.

  • Dass Task-Caching nicht unterstützt wird, ist für mich ein ziemlich großer Nachteil.
    Sobald es Abhängigkeiten im Task-Graphen gibt, sollte man bereits erledigte Tasks bei wiederholten Ausführungen nicht erneut starten, sondern aus dem Cache bedienen; gerade in mittelgroßen Monorepos ist das wichtig.
    Ich habe nach Plänen für so eine Funktion gesucht, aber im Mise-Repository waren Issues deaktiviert, und auch im README habe ich dazu nichts gefunden, was mein Vertrauen eher geschwächt hat.
    Wenn man ein einsprachiges npm-Monorepo nutzt, würde ich Wireit empfehlen.
    Wireit ergänzt npm-Skripte um Abhängigkeiten sowie lokales/GitHub-Actions-Caching und bietet langlebige Service-Tasks.
    Wireit GitHub

    • Mise unterstützt durchaus lokales Caching für Tasks wie Make.
      Das geht über die Angabe von sources und outputs; siehe Mise-Task-Konfigurationsleitfaden.
      Schon wenn nur sources angegeben sind, werden Änderungen an den Quellen automatisch nachverfolgt.
      Ich hatte diese Funktion vor langer Zeit zur Beschleunigung von Docker-Builds angefragt und nutze sie seitdem sehr nützlich.

    • Gerade dass mise sich weniger um den Quellcode des Projekts oder Bibliotheksabhängigkeiten kümmert, macht den Reiz seiner Einfachheit aus.
      Normalerweise bietet es nur bis zu genau dieser Grenze Funktionen.

    • Task-Caching passt nicht zur Ausrichtung von mise.
      Siehe die offizielle Anti-Goals-Dokumentation.
      turbopack, moonrepo und andere konzentrieren sich bereits auf dieses Problem.
      Mise wird wahrscheinlich eher ein leichtgewichtiger Task-Runner bleiben, der sich einfach auf das Ausführen von Skripten konzentriert.

    • Warum die Issues im Mise-Repository deaktiviert sind, weiß ich auch nicht.
      Früher gab es einmal ein Issue mit dem Hinweis, dass der Maintainer Discussions gegenüber Issues bevorzuge, aber das ist inzwischen verschwunden.
      Ich habe dazu diese Diskussion gestartet.
      Aus der Perspektive von jemandem, der das Projekt wie ich seit Jahren nutzt, habe ich großes Vertrauen darin und empfehle es auch in meinem Umfeld.
      Ich würde empfehlen, sich die Discussions und die praktische Nutzungserfahrung anzusehen.

    • Das ist ein bisschen so, als würde man von mise Build-System-Funktionen im Stil von bazel verlangen.
      Vielleicht erfüllt es diese Rolle teilweise ohnehin schon.
      Caching ist zwar nützlich, aber man muss aufpassen, dass zusätzliche Funktionen die Komplexität nicht zu stark erhöhen.
      Man könnte auch darüber nachdenken, wie man vorhandene Build-Systeme integriert.

  • mise sieht ziemlich gut aus.
    Aus Sicht eines aktuellen asdf-Nutzers zögere ich aber etwas, weil mise viele Dinge wie PATH-Manipulationen zu umfassend verwalten zu wollen scheint.
    Dass mehrere Tools PATH jeweils unterschiedlich verändern, ist wirklich lästig, deshalb habe ich PATH direkt in meiner .zprofile festgeschrieben und diverse Initialisierungsskripte komplett entfernt.
    Es wäre gut, wenn mise sowohl Programmiersprachen als auch die über diese Sprachen installierten CLI-Apps (cargo, go, uv usw.) auf einmal verwalten könnte, aber genau dieser Teil könnte beim Umstieg etwas nervig sein.

    • Du sagtest, dass es störend war, wie verschiedene Tools die PATH-Priorität manipulieren, aber mise macht das nicht so.
      Wenn man möchte, kann man Shims verwenden.
      Es unterstützt sowohl sprachspezifische Tools als auch die Verwaltung der Sprachen selbst.

    • Ich erinnere mich nicht mehr genau, warum ich damals von asdf zu mise gewechselt bin, aber ich nutze es seit Jahren ohne jedes Problem.

  • Ich halte mise für absolut erstklassig.
    Es ist genau richtig für Leute, denen Automatisierung, identische Umgebungs-Setups und schnelles Bootstrapping neuer Projekte wichtig sind.
    Besonders in Ruby-/Python-/Node-Umgebungen löst es Unterschiede bei individuellen Setups und die wiederholbare Reproduktion von Umgebungen auf einfache Weise, ganz ohne Dinge wie Docker.
    In kleinen Teams oder bei Einzelprojekten kann man damit wiederholbare CI-Umgebungen auch ohne dedizierte Build-Systeme wie Bazel oder Gradle leicht aufbauen.
    In Kombination mit chezmoi nutze ich es auch sehr gut zur Verwaltung lokaler System-Tools.

  • Ich bin vor Kurzem von just zu mise gewechselt.
    just ist ebenfalls hervorragend, bietet aber letztlich nur die Funktion eines Command-Runners, und ich brauchte die zusätzlichen Funktionen von mise.
    Ich finde, der Wechsel hat sich gelohnt.
    Allerdings wäre es gut, wenn Use Cases, Historie, Vergleiche mit anderen Tools wie nix oder docker und eine strukturelle Erklärung verständlicher dokumentiert wären, gerade für Einsteiger.
    Ich würde mir wünschen, dass anhand konkreter kleiner Unterschiede besser erklärt wird, warum man mise braucht und wodurch es sich klarer von bereits existierenden Tools abgrenzt.

  • Ich freue mich wirklich sehr über diese Neuigkeit.
    Es wirkt wie eine gelungene Mischung aus den Vorteilen einfacher Task-Runner wie just/taskfile und der Stärke von bazel/buck2.
    Ich bin gespannt, wie andere Leute es einsetzen werden, und freue mich auf neue Versuche damit.

    • Ich nutze mise ebenfalls hauptsächlich und bin fast vollständig zufrieden.
      Mein Workflow für Umgebungsverwaltung wurde stark vereinfacht.
      Die Task-Runner-Funktion brauche ich allerdings nicht unbedingt.
      Make oder just erfüllen diese Rolle bereits gut genug.
      Ich habe es zwar nicht in einem Monorepo eingesetzt, aber beide Tools unterstützen Imports und Erweiterungen für Task-/Recipe-Dateien, sodass sich je nach Bedarf sicher ein Setup bauen lässt.
      Die UX ist vielleicht nicht so nahtlos wie bei speziell dafür gebauten Tools, aber ich bevorzuge es, wenn jedes Tool sich auf eine einzelne Aufgabe konzentriert.
      mise deckt als Umgebungsmanager ohnehin schon viele Funktionen ab, daher wäre es mir lieber, wenn es sich darauf fokussiert.
      Soweit ich sehe, ist mein Gegenüber wohl der Autor von mise, also danke dafür.

  • Wenn man Tasks eines Repositories über einen einzigen Entry-Point verwalten möchte, könnte mein Projekt dela interessant sein.
    Es scannt verschiedene Task-Dateidefinitionen wie pyproject.toml, package.json und makefile und macht sie unter ihrem Task-Namen direkt über die CLI ausführbar.
    Ich konnte es in mehreren Repositories ohne Anpassungen sofort einsetzen, was sehr praktisch war, und ein weiterer Vorteil ist, dass man die Repository-Struktur nicht ändern muss.
    Mise-Tasks werden bisher noch nicht unterstützt, aber falls Interesse besteht, würde ich das sofort ergänzen.
    Einer aktuellen Auswertung zufolge wird mise in 94 der 100.000 GitHub-Repositories mit den meisten Stars verwendet.
    Weitere Daten finden sich im 2025 task runners census

    • Sieht großartig aus, aber unterstützt es auch eine vollständige Liste aller Tasks?
      Wenn ich ein Node-Projekt-Repository betrete, prüfe ich als Erstes immer mit npm run, welche Skripte vorhanden sind.
      Wenn es ein Makefile gibt, schaue ich hinein, aber wenn Targets oder Abhängigkeiten komplett über Variablen definiert sind, bin ich sofort wieder raus.

  • Ich hatte mir ohnehin gerade gewünscht, mise hätte so eine Funktion, deshalb freut es mich, dass sie jetzt neu erschienen ist.
    Am besten an mise gefällt mir die Möglichkeit, globale Tools im Hintergrund über npm, go, cargo usw. zu installieren.
    Zum Beispiel lässt sich mit einem simplen Befehl wie mise use -g npm:prettier sehr leicht etwas installieren.
    Früher musste ich mit nvm immer im Kopf behalten, unter welcher Node-Version ich globale Pakete installiert hatte, aber dank mise ist das viel bequemer geworden.
    Neulich gab es allerdings einen kleinen Bug: Als ich die neueste Node-Version installieren wollte, wurde stattdessen die zweitneueste installiert.

  • Wenn man eine pure Nix-shell verwenden kann, wirkt mise möglicherweise etwas weniger attraktiv.
    Trotzdem könnte es sich wegen der niedrigeren Lernkurve stärker verbreiten als Nix.

    • Gerade für das einfache Bootstrapping von Projekten für viele verschiedene Menschen und nicht nur für einen selbst oder den eigenen PC sticht mise wirklich hervor.
      Die TOML-basierte Konfiguration ist für die meisten Leute auch sehr leicht verständlich.
      Dinge, die früher lästig waren — README durchforsten, die Umgebung manuell angleichen, je nach Sprache unterschiedliche Installationswege — sind mit mise kein Problem mehr.
      Besonders vorteilhaft ist das bei der Verwaltung von Node-/Ruby-/Python-Umgebungen.

    • Ich habe ein Jahr lang nix-darwin verwendet und bin am Ende zu mise gewechselt.
      Mise erfüllt 90 % meiner Anforderungen mit nur 1 % des Aufwands.
      Ich mag die Konzepte von nix, und ich denke, dass Software-Builds in Zukunft definitiv stärker in diese Richtung gehen werden.
      Ich glaube nur, dass nix im Moment vielleicht noch nicht der Akteur ist, der das am Ende tragen wird.