Evaluate mise for polyglot monorepo tooling consolidation

[galligan]

Background

We currently manage runtimes, env, and task orchestration with multiple tools across the repo. This issue proposes evaluating mise as a single, consistent layer for:

• tool versions
• env management
• task running
• monorepo task namespacing

Reference docs:

• https://mise.jdx.dev/
• https://mise.jdx.dev/configuration.html
• https://mise.jdx.dev/tasks/monorepo.html
• https://mise.jdx.dev/tasks/running-tasks.html
• https://mise.jdx.dev/direnv.html
• https://mise.jdx.dev/faq.html
• https://mise.jdx.dev/continuous-integration.html
• https://github.com/marketplace/actions/mise-action

What could be consolidated with mise

Tool versions

• Replace scattered tool managers (e.g., asdf/nvm/pyenv) with a single mise.toml + per-dir overrides.

Environment management

• Replace or reduce reliance on direnv by defining env vars in mise.toml (per directory).

Task running

• Centralize build/test/lint/dev tasks in mise tasks (including deps + outputs), instead of Make/just/shell scripts.

Monorepo task namespacing (experimental)

• Use //path:task for package-scoped tasks and shared tasks, with inheritance from root configs.

CI bootstrapping

• Install toolchains in CI via jdx/mise-action or a bootstrap script.

Upsides

• Single source of truth for tools + env + tasks across the monorepo.
• Hierarchical config maps well to packages and workspace overrides.
• Task dependencies + outputs allow incremental task execution.
• Monorepo task namespacing reduces custom glue for package-specific commands.
• CI standardization via a single installation flow.

Downsides / Risks

• Monorepo mode is experimental and requires MISE_EXPERIMENTAL=1.
• direnv conflicts: mise recommends not using direnv simultaneously; we need a strategy.
• asdf compatibility is not a priority (some asdf-go behaviors may diverge).
• Potential migration cost (docs + scripts + onboarding).

Proposal (Evaluation Plan)

1. Add a minimal root mise.toml with core tool versions (Rust/Bun/etc.).
2. Pilot task definitions for a few common commands (build/test/lint).
3. Decide on env ownership (mise vs direnv), document the chosen approach.
4. Optionally enable monorepo root tasks if the experimental path is acceptable.
5. Validate CI setup using mise-action or a bootstrap script.

Decision Criteria

• Fewer tools required for onboarding
• Lower maintenance for tool versions + env vars
• Task usability (DX parity vs current tooling)
• Monorepo support adequate for our package layout
• CI compatibility and stability

Acceptance Criteria

• One documented workflow for tool versions and tasks
• Clear guidance on env management (including whether direnv stays)
• CI runs with mise in at least one pipeline
• No regressions in developer workflows

Open Questions

• Are Conventional Commit hooks / release tasks impacted by switching task runners?
• Should we keep .tool-versions for compatibility or migrate fully?
• How much do we want to rely on experimental monorepo features?

[linear]

BLZ-291

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[galligan]

@claude would it make sense to do this?

[claude]

Claude Code is working…

I'll analyze this and get back to you.

View job run