In a prior post—The Task Runner Spectrum—I covered Make, language tools like Mix, and Just. Since then, a colleague introduced me to mise. It’s an interesting tool, so in this post I’ll compare it with the others from that piece.

What Is Mise?

Mise is a single CLI that tackles the “clone and run” problem in polyglot projects:

  • Ensures consistent versions of runtimes and CLIs (Node, Python, Ruby, Bun, Terraform, etc.)
  • Installs tools automatically based on project config
  • Adds shims so your shell sees node, python, etc. at the right versions per project
  • Includes a small task runner via mise run <task>

Think of mise as asdf plus a bit of direnv, with a pinch of just. The superpower is repeatable onboarding: clone the repo, run mise run setup, and the toolchain appears.

Is Mise a Build Tool?

No. Mise doesn’t do incremental builds, dependency graphs, or artifact tracking. It won’t replace Make or language‑native build tools. If your need is efficient rebuilds based on file changes, use a build system. Mise helps before the build: it ensures the right runtimes and CLIs exist, then runs consistent commands.

Is Mise a Version Manager?

Yes—and more. Mise is mainly a version and tool manager with per‑project pinning. It supports multiple tools in one config, resolving versions from mise.toml (and it can read versions from other files like .tool-versions or package.json).

Key parts:

  • Global and per‑project versions
  • Shims on your PATH for fast resolution
  • Plugins/backends for many tools
  • A trust model for auto‑install when you enter a directory

If you only need version management, mise can replace asdf/nvm/pyenv with a single, cohesive tool.

Is Mise a Task Runner?

Yes—lightweight and pragmatic. Mise tasks live in mise.toml and run with mise run <task>. Features include:

  • Variables, env injection, and dotenv integration
  • Dependencies between tasks
  • Default task and grouping
  • Shell‑agnostic command execution

Compared to Just, mise’s task runner is simpler and intentionally tied to its environment management. It’s great for bootstrapping (setup, install, fmt, test), but it’s not meant for complex orchestration or cross‑platform recipe nuances.

Mise vs Make vs Just

Feature Make Just Mise
Role Build system Command runner Tool/version manager + light task runner
Installation Pre-installed on Unix Single binary install Single binary; installs other tools for you
Cross-platform Weak on native Windows Excellent (Windows/macOS/Linux) Excellent (Windows/macOS/Linux)
Syntax complexity High (quirky, tabs) Low (clean recipes, params) Low (simple mise.toml tasks)
Language-agnostic Yes Yes Yes
Incremental builds Yes (file deps) No No
Environment management No No Yes (versions, shims, auto-install)
Task runner capability Basic via shell targets Strong, ergonomic Basic, tied to environment
Discoverability make help if implemented just --list built-in mise tasks / mise run --list
Best for Artifact builds and dependency graphs Cross-platform orchestration Fast onboarding, consistent toolchains, common tasks

When to Use Which

  • Pure build pipelines with file dependencies → Make (or language‑native build tool)
  • Polyglot orchestration and developer‑friendly tasks → Just
  • Fast onboarding + consistent tool versions + common tasks → Mise
  • Combine Mise + Just: mise installs tools; Just orchestrates commands
  • Combine Mise + Make: mise ensures compilers/toolchains; Make handles builds

Migration Thoughts

If you use asdf + just, mise can replace asdf while keeping Just. If you use Make mainly for developer commands (not builds), consider moving those to Just or mise tasks for readability and cross‑platform support.

If you want a single tool, mise is compelling. For complex orchestration, Just wins. For build graphs, use Make or language‑native tools.

Conclusion

Mise sits next to Make and Just, not in competition with build systems. It’s the glue for environments and toolchains and a convenient place for common tasks. In practice, a strong setup for polyglot teams is:

  • Mise to pin and auto-install tools
  • Just to orchestrate daily commands
  • Make or language-native tools to build artifacts

That mix cuts onboarding pain, improves repeatability, and keeps responsibilities clear.

See you in the next post.