Mise: apresentação do recurso de tarefas para monorepos

 (github.com/jdx)
7 pontos por GN⁺ 2025-10-07 | 2 comentários | Compartilhar no WhatsApp
  • O mise anunciou um novo recurso de tarefas para monorepos
  • Ele oferece um namespace unificado de tarefas para gerenciar com facilidade ambientes, ferramentas e tarefas de vários projetos
  • Inclui vários recursos, como padrões curinga poderosos, herança de ambiente/ferramentas e contexto de execução consistente
  • Oferece simplicidade e flexibilidade para monorepos com várias linguagens ou ambientes complexos
  • Em comparação com Bazel, Turborepo e outros, seus pontos fortes são independência de linguagem, configuração simples e gerenciamento unificado

Introdução: anúncio do recurso de tarefas para monorepos

  • O mise introduziu um novo recurso chamado Monorepo Tasks
  • Ele oferece suporte de primeira classe a monorepos, permitindo manter de forma independente e gerenciar com eficiência ferramentas, variáveis de ambiente e tarefas de cada projeto em repositórios com vários projetos

Principais recursos

  • Namespace unificado de tarefas: descobre automaticamente todas as tarefas dentro do monorepo e as diferencia claramente com prefixos baseados na localização
    Exemplo:
    mise //projects/frontend:build
    mise //services/api:deploy
  • Herança inteligente de ferramentas e ambiente: é possível definir ferramentas comuns na raiz e, se necessário, sobrescrevê-las em projetos filhos
    • Ex.: as configurações node=20 e python=3.12 no mise.toml da raiz são herdadas automaticamente por todos os subprojetos
    • Em um projeto específico (mise.toml), é possível sobrescrever para node=14, enquanto a configuração superior de python continua sendo herdada
  • Padrões curinga poderosos:
    • Executar os testes de todos os projetos: mise //...:test
    • Executar todos os builds em services/: mise //services/...:build
    • Executar todas as tarefas dentro de frontend: mise '//projects/frontend:*'
    • Também é possível executar grupos de acordo com o nome da tarefa
  • Execução consistente em qualquer lugar: independentemente de onde a tarefa seja executada, ela roda com o ambiente e as ferramentas definidos no config_root daquela tarefa
  • Propagação automática de confiança: ao registrar confiança (Trust) apenas na raiz do monorepo, as configurações filhas passam a ser confiáveis automaticamente

Guia de início rápido

  1. No mise.toml da raiz, defina experimental_monorepo_root=true
  2. Ative o sinalizador experimental (MISE_EXPERIMENTAL=1)
  3. Adicione tasks ao mise.toml de cada projeto
    • Ex.:
      [tasks.build]
      run = "npm run build"
  4. Execute a tarefa desejada na raiz ou em qualquer caminho
    • mise //projects/frontend:build
    • mise //...:test

Exemplo de estrutura 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
  • Executar o build de todos os serviços: mise //services/...:build
  • Testar todos os apps: mise //apps/...:test
  • Todas as tarefas: mise '//...:*'

Contexto e efeitos esperados da adoção

  • Surgiu da necessidade de lidar com a complexidade do gerenciamento de monorepos e com scripts repetitivos
  • Definir uma vez, executar em qualquer lugar, para minimizar duplicações
  • Aplicação automática das ferramentas/ambientes corretos para cada projeto
  • Simplificação dos pipelines de CI/CD com curingas poderosos
  • Melhor navegação e entendimento com o namespace de tarefas

Comparação com as principais ferramentas existentes

  • Simple Task Runners (Taskfile, Just etc.)

    • Otimizados para automação em um único projeto; em monorepos, não oferecem namespace unificado, herança nem curingas
    • O mise oferece descoberta automática de tarefas e suporte a padrões avançados

  • Ferramentas centradas em JavaScript (Nx, Turborepo, Lerna)

    • Fortes em monorepos JS/TS (dependency graph, codegen, cache etc.)
    • O mise é agnóstico de linguagem, atende a várias linguagens/stacks e oferece gerenciamento unificado de ferramentas/variáveis de ambiente

  • Sistemas de build de grande escala (Bazel, Buck2)

    • Oferecem cache distribuído, execução remota etc., mas têm alta complexidade e curva de aprendizado, além de muitas restrições estruturais
    • O mise adota uma abordagem non-hermetic, com configuração flexível e adoção fácil

  • Outros (Rush, Moon etc.)

    • Rush: orquestração de builds voltada a JS
    • Moon: baseado em Rust, com foco em suporte multilíngue

O que torna o mise Monorepo Tasks especial

Recurso Simple Runners Especializadas em JS Build Systems mise
Suporte a múltiplas linguagens ✅ ❌ ✅ ✅
Facilidade de aprendizado ✅ ⚠️ ❌ ✅
Descoberta unificada de tarefas ❌ ✅ ✅ ✅
Padrões curinga ❌ ⚠️ ✅ ✅
Gerenciamento de versões de ferramentas ❌ ❌ ⚠️ ✅
Herança de ambiente ❌ ⚠️ ❌ ✅
Configuração mínima ✅ ⚠️ ❌ ✅
Cache de tarefas ❌ ✅ ✅ ❌
  • Quando escolher o Mise?
    • Monorepos com mistura de linguagens
    • Gerenciamento unificado de ferramentas e tarefas
    • Quando se prefere simplicidade
    • Adequado para quem já usa mise
  • Quando considerar outra opção
    • Foco apenas em JS/TS → Nx, Turborepo
    • Empresas gigantes em escala extrema (Google/Meta etc.) → Bazel, Buck2
    • Necessidade de cache avançado de tarefas → Nx, Turborepo, Bazel

Conclusão

  • O recurso de tarefas para monorepos do mise foi projetado para permitir o gerenciamento fácil e consistente de monorepos complexos em ambientes com várias linguagens, sem se limitar a uma única linguagem
  • Com configuração mínima e padrões de tarefas poderosos, ele melhora tanto a produtividade quanto a experiência dos desenvolvedores
  • É muito mais simples e flexível do que soluções empresariais complexas

Leituras relacionadas

2 comentários

 
GN⁺ 2025-10-07
Comentários do Hacker News

  • Antes, quando eu usava principalmente Python, não via muito o apelo do Mise; achava que o uv já bastava
    Mas quando precisei alinhar versões por diretório, como no Node, e ter pontos de entrada comuns como mise build ou mise test independentemente da linguagem ou do tipo de projeto, percebi de verdade o valor do Mise
    Também gosto muito do Just como runner de tarefas, e graças a ele consegui me livrar do Make
    O Make é poderoso, mas deixava a desejar na experiência de desenvolvimento
    O Just pode até ser mais poderoso em recursos do que a função de tasks do Mise, mas o Mise combina uma função de tasks bastante boa com um excelente gerenciamento de ferramentas, e para mim essa é a melhor combinação

    • Como fã de Makefiles simples, fiquei curioso para saber que vantagens você viu ao sair do Make, passar pelo Just e chegar ao Mise

    • Eu gostava muito do just, mas acertar exatamente o ambiente no just task era trabalhoso, e carregar ambientes virtuais também era um incômodo
      Por isso acabei migrando para o mise por motivos parecidos

  • Tenho expectativas enormes com o mise
    Ele rapidamente virou uma ferramenta essencial sempre que começo um projeto novo
    É muito prático ter em um único arquivo de configuração o gerenciamento de várias ferramentas, como node, python, rust e go, junto com um substituto de makefile fácil de usar
    Em geral, configuro um hook de postinstall, então quando alguém pega meu projeto basta rodar mise install para instalar automaticamente a versão certa das ferramentas e até os pacotes de dependência, o que facilita muito
    Enquanto o nix me parece ter uma barreira de entrada alta, o mise parece bem mais prático

    • Se a abordagem do Nix parecer pesada, ferramentas como devenv.sh aumentam bastante a acessibilidade
      Por exemplo, com languages.rust.enable = true já dá para configurar na hora um ambiente de desenvolvimento Rust
      Além disso, você pode incluir scripts, tasks e pacotes

    • Fiquei curioso se você poderia compartilhar um exemplo de configuração
      Parece interessante
      Tenho usado just e docker(-compose) em projetos monorepo, e minhas tentativas com moon & proto foram curtas e um pouco decepcionantes
      Gosto da simplicidade do just, mas o onboarding de novos membros em várias plataformas ainda é trabalhoso

    • Eu também configurei um projeto novo com mise
      É excelente porque facilita muito o começo para quem está chegando, sem etapas manuais

    • Achei interessante você usar hook de postinstall no mise
      Fiquei curioso sobre o que você costuma colocar nele

  • O fato de não suportar cache de task é uma limitação considerável
    Quando surgem dependências em um grafo de tarefas, o ideal é que tasks já concluídas sejam resolvidas por cache em vez de serem executadas de novo, o que é importante para eficiência em execuções repetidas, especialmente em monorepos de porte médio
    Procurei se havia planos para isso, mas no repositório do Mise as issues estavam desativadas e não havia menção no README, o que me passou pouca confiança
    Se eu estivesse usando um monorepo npm de uma única linguagem, recomendaria o Wireit
    O Wireit adiciona dependências e cache local/GitHub Actions a scripts npm, além de oferecer tasks do tipo serviço de longa duração
    Wireit GitHub

    • O Mise também suporta cache local de tasks, como o Make
      Isso funciona se você definir sources e outputs, e dá para ver na documentação de configuração de tasks do mise
      Só de definir sources ele já faz o rastreamento automático de mudanças
      Pedi esse recurso há bastante tempo para acelerar builds com Docker e tenho usado bastante

    • Para mim, justamente o fato de o mise se preocupar menos com o código-fonte do projeto ou com dependências de bibliotecas é parte do apelo da simplicidade
      Em geral ele oferece recursos só até essa fronteira

    • Cache de task vai contra a proposta do mise
      Veja o documento oficial de anti-goals
      turbopack, moonrepo e outros já focam nesse problema
      O mais provável é que o mise continue sendo um task runner leve, focado simplesmente em executar scripts

    • Também não sei por que as issues do repositório do Mise estão desativadas
      Antes havia uma issue dizendo algo como “o mantenedor prefere discussions a issues”, mas agora ela sumiu
      Abri esta discussão sobre o assunto
      Como alguém que usa a ferramenta há alguns anos, tenho bastante confiança no projeto e o recomendo a outras pessoas
      Eu sugeriria olhar as discussions e a experiência prática de uso

    • Isso parece um pouco como pedir ao mise recursos de sistema de build no estilo bazel
      Talvez ele até já cumpra um pouco esse papel
      Cache é útil, mas é preciso cuidado para que novos recursos não aumentem demais a complexidade
      Também vale pensar em formas de integração com sistemas de build existentes

  • O mise parece bem interessante
    Só que, como usuário atual do asdf, fico um pouco receoso porque o mise parece querer gerenciar coisas demais, como manipulação de PATH
    É realmente irritante quando várias ferramentas mexem no PATH de maneiras diferentes, então acabei fixando o PATH manualmente no .zprofile e removendo vários scripts de inicialização
    Seria ótimo se o mise gerenciasse de uma vez tanto linguagens de programação quanto apps CLI instalados por essas linguagens, como cargo, go e uv, mas essa parte também parece um pouco trabalhosa na hora de migrar

    • Você comentou que era incômodo várias ferramentas mexerem na prioridade do PATH, mas o mise não faz isso
      Se quiser, você pode usar shim
      Ele suporta tanto o gerenciamento das linguagens quanto das ferramentas específicas de cada uma

    • Não lembro exatamente por que troquei o asdf pelo mise, mas uso há alguns anos sem nenhum problema

  • Acho o mise fantástico
    É ideal para quem leva a sério automação, configuração de ambientes idênticos e bootstrap rápido de novos projetos
    Especialmente em ambientes Ruby/Python/Node, ele resolve de forma simples, sem precisar de Docker ou algo do tipo, as diferenças de setup e a repetição de ambientes
    Em times pequenos ou projetos pessoais, dá para criar com facilidade um ambiente reproduzível sem depender de CI nem de um sistema de build como Bazel ou Gradle
    Também tenho usado junto com o chezmoi para gerenciar ferramentas do sistema local

  • Migrei recentemente do just para o mise
    O just também é excelente, mas oferece apenas a função de runner de comandos, e eu precisava dos recursos extras do mise
    Acho que foi uma boa mudança
    Ainda assim, seria bom se houvesse uma explicação melhor sobre casos de uso, histórico, comparação com outras ferramentas como nix e docker, e uma descrição mais estrutural
    Gostaria que a documentação mostrasse com mais clareza, por meio de exemplos concretos, o “porquê” do mise e o que o diferencia de outras ferramentas que já existem

  • Estou realmente animado com essa novidade
    Parece combinar bem as vantagens de task runners simples como just/taskfile com a potência de ferramentas como bazel/buck2
    Fico curioso para ver como outras pessoas vão usar isso e estou empolgado com as novas possibilidades

    • Eu também uso mise como principal ferramenta e estou quase totalmente satisfeito
      O fluxo de gerenciamento de ambiente ficou muito mais simples
      Mas eu não sinto necessidade da função de task runner
      Make ou just já cumprem bem esse papel
      Nunca usei isso num monorepo de verdade, mas ambas as ferramentas suportam importação e extensão de arquivos de task/recipe, então imagino que dê para montar algo conforme a necessidade
      Talvez a UX não fique tão fluida quanto a de uma ferramenta feita sob medida, mas prefiro que cada ferramenta tenha um papel único
      O mise já acumula bastante coisa no papel de gerenciador de ambiente, então seria bom focar mais nisso
      Aliás, acho que você é o autor do mise; obrigado

  • Se você quer gerenciar as tasks de um repositório a partir de um único ponto de entrada, talvez valha considerar dela, que eu criei
    Ele varre definições de task em vários formatos, como pyproject.toml, package.json e makefile, e permite executá-las direto pela CLI usando o nome da task
    Em vários repositórios eu consegui usá-lo imediatamente, sem nenhuma adaptação, o que foi muito conveniente, e outra vantagem é não precisar mudar a estrutura do repositório
    Ele ainda não suporta tasks do mise, mas se houver demanda posso adicionar isso rapidamente
    Segundo uma contagem recente, o mise é usado em 94 dos 100 mil repositórios mais estrelados do GitHub
    Para mais detalhes, veja o censo de task runners de 2025

    • Parece legal; fiquei curioso se ele também suporta listar todas as tasks
      Quando entro em um repositório de projeto Node, a primeira coisa que sempre faço é rodar npm run para ver a lista de scripts
      Se houver um Makefile, eu dou uma olhada, mas se os targets ou dependências estiverem todos escondidos em variáveis, saio na hora

  • Eu estava justamente pensando que seria bom se o mise tivesse uma função assim, então foi ótimo ver que ela acabou de sair
    A coisa de que mais gostei ao usar o mise foi poder instalar ferramentas globais de backend via npm, go, cargo e afins
    Por exemplo, dá para instalar facilmente com um comando simples como mise use -g npm:prettier
    Antes, quando eu usava nvm, precisava sempre lembrar em qual versão do node tinha instalado cada pacote global, e com o mise isso ficou bem mais prático
    Só tive um pequeno bug recentemente: tentei instalar a versão mais recente do node, mas ele instalou a penúltima

  • Se você consegue usar pure Nix-shell, o mise pode perder um pouco do apelo
    Ainda assim, como a curva de aprendizado é menor do que a do Nix, acho que ele pode acabar se espalhando mais

    • O mise realmente se destaca quando a necessidade é facilitar o bootstrap de um projeto para várias pessoas, e não só para você ou para o seu próprio computador
      A configuração baseada em TOML também é muito simples de entender
      Aquelas situações em que antes era preciso vasculhar README, acertar o ambiente manualmente e lidar com métodos diferentes de instalação por linguagem deixam de ser um problema com o mise
      Isso é especialmente vantajoso ao gerenciar ambientes Node/Ruby/Python

    • Usei nix-darwin por um ano e no fim migrei para o mise
      O mise atende a 90% do que eu preciso com apenas 1% da dor de cabeça
      Acho os conceitos do nix excelentes e acredito que o futuro da forma como software será construído vai claramente nessa direção
      Só não tenho certeza de que, no momento, o agente principal desse futuro será o nix mesmo