Mise: presentación de la función de tareas para monorepos

 (github.com/jdx)
7 puntos por GN⁺ 2025-10-07 | 2 comentarios | Compartir por WhatsApp
  • mise anunció una nueva función de tareas para monorepos
  • Proporciona un espacio de nombres unificado de tareas para gestionar fácilmente entornos, herramientas y tareas de múltiples proyectos por separado
  • Incluye varias funciones como potentes patrones con comodines, herencia de entorno/herramientas y un contexto de ejecución consistente
  • Ofrece simplicidad y flexibilidad para monorepos con múltiples lenguajes o entornos complejos
  • Frente a Bazel, Turborepo y otros, sus fortalezas son la independencia del lenguaje, configuración sencilla y gestión unificada

Introducción: anuncio de la función de tareas para monorepos

  • mise introdujo una nueva función llamada Monorepo Tasks
  • Ofrece soporte de primer nivel para monorepos que permite mantener de forma independiente y gestionar eficientemente herramientas, variables de entorno y tareas por proyecto dentro de un repositorio con múltiples proyectos

Funciones principales

  • Espacio de nombres unificado de tareas: descubre automáticamente todas las tareas dentro del monorepo y las distingue claramente agregando prefijos según su ubicación
    Ejemplo:
    mise //projects/frontend:build
    mise //services/api:deploy
  • Herencia inteligente de herramientas y entorno: se pueden definir herramientas comunes en la raíz y, si es necesario, sobrescribirlas en proyectos hijos
    • Ejemplo: la configuración node=20, python=3.12 del mise.toml raíz se hereda automáticamente en todos los subproyectos
    • En un proyecto específico (mise.toml) se puede sobrescribir con node=14, mientras que la configuración superior de python se sigue heredando
  • Potentes patrones con comodines:
    • Ejecutar pruebas en todos los proyectos: mise //...:test
    • Ejecutar todos los builds bajo services/: mise //services/...:build
    • Ejecutar todas las tareas dentro de frontend: mise '//projects/frontend:*'
    • También permite ejecutar grupos según el nombre de la tarea
  • Ejecución consistente en cualquier momento: sin importar desde dónde se ejecute una tarea, se ejecuta con el entorno y las herramientas definidos en el config_root de esa tarea
  • Propagación automática de confianza: si solo se marca como confiable la raíz del monorepo (Trust), las configuraciones hijas también se consideran confiables automáticamente

Guía de inicio rápido

  1. Configurar experimental_monorepo_root=true en el mise.toml raíz
  2. Activar la bandera experimental (MISE_EXPERIMENTAL=1)
  3. Agregar tareas en el mise.toml de cada proyecto
    • Ejemplo:
      [tasks.build]
      run = "npm run build"
  4. Ejecutar la tarea deseada desde la raíz o cualquier ruta
    • mise //projects/frontend:build
    • mise //...:test

Ejemplo de estructura 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
  • Ejecutar el build de todos los servicios: mise //services/...:build
  • Ejecutar pruebas de todas las apps: mise //apps/...:test
  • Todas las tareas: mise '//...:*'

Contexto de adopción y efectos

  • Nació a partir de la complejidad de administrar monorepos y de las preocupaciones sobre scripts repetitivos
  • Definir una vez, ejecutar en cualquier lugar para minimizar la duplicación
  • Aplicación automática del entorno y las herramientas correctas para cada proyecto
  • Simplificación de pipelines de CI/CD con potentes comodines
  • Mejor navegación y comprensión con un espacio de nombres de tareas

Comparación con herramientas existentes

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

    • Optimizados para automatización en un solo proyecto; en monorepos no ofrecen espacio de nombres unificado, herencia ni comodines
    • mise ofrece descubrimiento automático de tareas y soporte de patrones potentes

  • Herramientas centradas en JavaScript (Nx, Turborepo, Lerna)

    • Muy potentes en monorepos JS/TS (dependency graph, codegen, cache, etc.)
    • mise es independiente del lenguaje, se adapta a varios lenguajes/stacks y soporta gestión unificada de herramientas y variables de entorno

  • Sistemas de build a gran escala (Bazel, Buck2)

    • Ofrecen caché distribuido, ejecución remota, etc., pero tienen alta complejidad y curva de aprendizaje, además de más restricciones estructurales
    • mise permite un enfoque no hermético (non-hermetic), con configuración flexible y adopción sencilla

  • Otros (Rush, Moon, etc.)

    • Rush: orquestación de builds solo para JS
    • Moon: basado en Rust, orientado a soporte multilenguaje

Qué hace especial a mise Monorepo Tasks

Función Simple Runners Especializadas en JS Build Systems mise
Soporte multilenguaje ✅ ❌ ✅ ✅
Fácil de aprender ✅ ⚠️ ❌ ✅
Descubrimiento unificado de tareas ❌ ✅ ✅ ✅
Patrones con comodines ❌ ⚠️ ✅ ✅
Gestión de versiones de herramientas ❌ ❌ ⚠️ ✅
Herencia de entorno ❌ ⚠️ ❌ ✅
Configuración mínima ✅ ⚠️ ❌ ✅
Caché de tareas ❌ ✅ ✅ ❌
  • ¿Cuándo elegir Mise?
    • Monorepos con lenguajes mixtos
    • Gestión unificada de herramientas y tareas
    • Cuando se prefiere la simplicidad
    • Adecuado para quienes ya usan mise
  • Cuándo considerar otra opción
    • Enfoque solo en JS/TS → Nx, Turborepo
    • Entornos enterprise muy grandes (Google/Meta, etc.) → Bazel, Buck2
    • Necesidad de caché avanzada de tareas → Nx, Turborepo, Bazel

Conclusión

  • La función de tareas para monorepos de mise está diseñada para gestionar de forma fácil y consistente monorepos complejos en entornos de múltiples lenguajes, sin limitarse a un solo lenguaje
  • Con una configuración mínima y patrones de tareas potentes, mejora tanto la productividad como la experiencia del desarrollador
  • Es mucho más simple y flexible que las soluciones enterprise complejas

Lecturas relacionadas

2 comentarios

 
GN⁺ 2025-10-07
Opiniones de Hacker News

  • Antes, cuando usaba principalmente Python, no terminaba de ver el atractivo de Mise; pensaba que con uv bastaba.
    Pero cuando necesitas ajustar versiones por directorio, como con Node, y tener puntos de entrada comunes como mise build o mise test sin importar el lenguaje o el tipo de proyecto, ahí sí se nota el verdadero valor de Mise.
    También me gusta mucho Just como runner de tareas, y gracias a eso pude dejar atrás Make.
    Make es potente, pero en experiencia de desarrollo siempre me quedó debiendo.
    Puede que Just sea más potente en funciones que la característica de tareas de Mise, pero para mí Mise ofrece una función de tareas bastante buena junto con una gestión de herramientas excelente, así que es la mejor combinación

    • Como fan de los Makefile simples, me da curiosidad saber qué ventajas viste al pasar de Make a Just y luego a Mise

    • Me gustaba mucho just, pero en las tareas de just era engorroso dejar el entorno configurado exactamente como debía, y también era molesto cargar entornos virtuales.
      Por eso me cambié a mise por razones parecidas

  • Tengo muchísimas expectativas con mise.
    Se volvió rápidamente una herramienta imprescindible cada vez que arranco un proyecto nuevo.
    Es muy cómodo poder gestionar varias herramientas como node, python, rust y go, además de tener un reemplazo de makefile fácil de usar, todo en un solo archivo de configuración.
    Por lo general configuro un hook postinstall, de modo que cuando alguien toma mi proyecto solo necesita ejecutar mise install y automáticamente se instalan las versiones correctas de las herramientas y hasta los paquetes de dependencias; realmente facilita todo.
    Mientras que Nix me parece tener una barrera de entrada alta, mise se siente mucho más práctico

    • Si el enfoque de Nix te resulta pesado, una herramienta como devenv.sh mejora muchísimo la accesibilidad.
      Por ejemplo, con languages.rust.enable = true puedes dejar listo de inmediato un entorno de desarrollo en rust.
      Además puedes agregar scripts, tareas y paquetes

    • ¿Podrías compartir una configuración de ejemplo?
      Suena interesante.
      He usado just y docker(-compose) en proyectos monorepo, y mis intentos con moon y proto fueron breves y algo decepcionantes.
      Me gusta la simplicidad de just, pero al incorporar gente nueva en varias plataformas sigue siendo algo engorroso

    • Yo también probé configurar un proyecto nuevo con mise.
      Es excelente porque la gente que llega nueva puede empezar mucho más fácilmente, sin pasos manuales

    • Me parece interesante lo de usar un hook postinstall en mise.
      ¿Qué sueles poner ahí?

  • Que no soporte caché de tareas es una desventaja bastante importante.
    Cuando aparecen dependencias en el grafo de tareas, las tareas ya completadas deberían resolverse desde caché en vez de volver a ejecutarse, para que las repeticiones sean eficientes; eso importa especialmente en monorepos medianos.
    Busqué si había planes para esa función, pero el repositorio de Mise tenía los issues desactivados y en el README no vi ninguna mención relacionada, así que no me dio mucha confianza.
    Si usas un monorepo npm de un solo lenguaje, recomiendo Wireit.
    Wireit agrega dependencias y caché local/de GitHub Actions a los scripts de npm, y ofrece tareas tipo servicio de larga ejecución.
    Wireit GitHub

    • Mise también soporta caché local de tareas al estilo de Make.
      Se puede si defines sources y outputs; lo puedes ver en la guía de configuración de tareas de mise.
      Incluso con solo indicar sources, el seguimiento de cambios en los sources se hace automáticamente.
      Pedí esa función hace tiempo para acelerar builds de Docker y la he estado usando muchísimo

    • Justamente es atractivo que mise se preocupe menos por el código fuente del proyecto o por las dependencias de librerías; esa simplicidad es parte de su encanto.
      Normalmente sus funciones llegan solo hasta ese límite

    • El caché de tareas va en contra de la dirección que busca mise.
      Ver la documentación oficial de anti-goals.
      turbopack, moonrepo y otros ya están enfocados en ese problema.
      Lo más probable es que mise siga siendo un runner de tareas ligero centrado simplemente en ejecutar scripts

    • No sé por qué desactivaron los issues en el repositorio de Mise.
      Antes había un issue que decía algo como “el maintainer prefiere discussions antes que issues”, pero ahora ya no está.
      Inicié esta discusión sobre el tema.
      Después de usar el proyecto durante varios años, yo sí le tengo mucha confianza y se lo recomiendo a gente cercana.
      Te sugeriría revisar las discussions y la experiencia real de uso

    • Es parecido a pedirle a mise funciones de sistema de build al estilo bazel.
      De hecho, quizá ya está cumpliendo un poco ese papel.
      La función de caché sería útil, pero hay que tener cuidado porque añadirla podría aumentar la complejidad.
      También valdría la pena pensar en formas de integrarlo con sistemas de build existentes

  • mise se ve bastante bien.
    Aunque como usuario actual de asdf, me hace dudar un poco que mise parezca querer gestionar demasiadas cosas, como la manipulación de PATH.
    Es realmente molesto que varias herramientas toquen PATH cada una a su manera, así que terminé fijando PATH yo mismo en .zprofile y eliminando varios scripts de inicialización.
    Estaría bueno que mise administrara de una vez tanto los lenguajes de programación como las apps CLI instaladas desde esos lenguajes (cargo, go, uv, etc.), aunque esa parte también parece un poco incómoda al momento de migrar

    • Dijiste que te molestaba que varias herramientas manipularan la prioridad de PATH, pero mise no funciona así.
      Si quieres, puedes usar shims.
      Soporta tanto la gestión de herramientas específicas de cada lenguaje como la del propio lenguaje

    • No recuerdo exactamente por qué pasé de asdf a mise antes, pero llevo años usándolo sin ningún problema

  • Me parece que mise es de lo mejor.
    Le queda perfecto a la gente que realmente se toma en serio la automatización, la configuración de entornos idénticos y el arranque rápido de proyectos nuevos.
    En particular, resuelve de forma sencilla —sin recurrir a cosas como Docker— las diferencias de configuración entre entornos Ruby/Python/Node y los problemas de reproducir una y otra vez el mismo entorno.
    En equipos pequeños o proyectos personales, permite construir fácilmente un entorno repetible sin necesitar CI ni sistemas de build como Bazel o Gradle.
    También lo uso muy bien junto con chezmoi para administrar herramientas del sistema local

  • Hace poco me pasé de just a mise.
    just también es excelente, pero solo ofrece la función de runner de comandos, y yo necesitaba las funciones adicionales de mise.
    Siento que fue una buena decisión haberme cambiado.
    Aun así, me gustaría que la documentación explicara mejor, para quienes empiezan, los casos de uso, la historia, la comparación con otras herramientas como nix o docker, y una explicación más estructurada.
    Ojalá se documente con más claridad el “por qué” de mise, revisando ejemplos de diferencias sutiles en la práctica y dejando más claras sus diferencias frente a otras herramientas que ya existen

  • Esta noticia me entusiasma mucho.
    Me da la impresión de combinar bastante bien las ventajas de runners de tareas simples como just/taskfile con la potencia de herramientas como bazel/buck2.
    Me interesa ver cómo la aprovechará otra gente y qué nuevas ideas salen de esto

    • Yo también uso mise como herramienta principal y en general estoy casi completamente satisfecho.
      El flujo de trabajo para gestionar entornos se simplificó mucho.
      Pero la función de task runner en sí no me hace falta.
      Make o just ya cumplen suficientemente bien ese papel.
      No lo he usado realmente en un monorepo, pero entiendo que ambas herramientas soportan importación y extensión de archivos de tareas/recetas, así que deberían permitir un setup según se necesite.
      Puede que la UX no sea tan fluida como la de una herramienta hecha a medida, pero prefiero que cada herramienta se concentre en una sola función.
      mise ya abarca bastantes cosas como gestor de entornos, así que me gustaría que siguiera enfocándose en eso.
      Por cierto, creo que la otra persona es el autor de mise; gracias

  • Si quieres gestionar las tareas del repositorio desde un punto de entrada único, podría valer la pena considerar dela, que hice yo.
    Escanea definiciones de tareas en distintos archivos como pyproject.toml, package.json y makefile, y permite ejecutarlas directamente desde el CLI usando el nombre de la tarea.
    Me resultó muy cómodo porque podía usarlo de inmediato en varios repos sin necesidad de hacer mejoras, y además no hace falta cambiar la estructura del repo.
    Todavía no soporta las tareas de mise, pero si hay demanda estaría dispuesto a agregarlo enseguida.
    Según un recuento reciente, mise se usa en 94 de los 100 mil repositorios con más estrellas en GitHub.
    Para más datos, ver 2025 task runners census

    • Se ve genial, pero me pregunto si también soporta una lista completa de tareas.
      Cuando entro a un repositorio de un proyecto Node, lo primero que hago siempre es ejecutar npm run para revisar la lista de scripts.
      Si hay un Makefile, lo reviso, pero si los targets o dependencias están todos metidos en variables, me salgo de inmediato

  • Justo estaba pensando que estaría bueno que mise tuviera una función así, así que me alegra ver que ya salió.
    Lo que más me gustó al usar mise fue la capacidad de instalar herramientas globales en segundo plano usando npm, go, cargo, etc.
    Por ejemplo, se puede instalar fácilmente con un comando simple como mise use -g npm:prettier.
    Antes, cuando usaba nvm, siempre tenía que acordarme en qué versión de node había instalado cada paquete global, pero con mise eso se volvió mucho más cómodo.
    Aunque hace poco, cuando intenté instalar la versión más reciente de node, hubo un pequeño bug y se instaló la segunda más reciente

  • Si puedes usar un pure Nix-shell, mise quizá pierde un poco de atractivo.
    Aun así, como la curva de aprendizaje es menor que la de Nix, siento que podría difundirse mucho más

    • mise realmente destaca si lo ves desde la perspectiva de facilitar el bootstrap de un proyecto para muchas personas distintas, no solo para ti o tu propia PC.
      Además, una configuración basada en TOML es muy fácil de entender para la gente.
      Cosas que antes implicaban rebuscar en el README, ajustar el entorno a mano y lidiar con métodos de instalación distintos según el lenguaje, en mise dejan de ser un problema.
      Es especialmente ventajoso al gestionar entornos de Node/Ruby/Python

    • Usé nix-darwin durante un año y al final me cambié a mise.
      mise me cubre el 90% de lo que necesito con apenas el 1% de la molestia.
      Los conceptos de nix me gustan, y creo que el futuro de cómo se construye software claramente va en esa dirección.
      Solo que, por ahora, quizá nix no sea quien termine liderándolo