When I was primarily using Python, I didn't really "get" Mise. Uh, that's what we have uv for! But it really shines when using things like Node where you want a specific version in each directory, and also want common entrypoints like `mise build` or `mise test` in every repo, regardless of its language(s).
Don't get me wrong: I also adore Just as a task runner. It's what got me off of Make, which is incredibly powerful but somewhat lacking in the DevEx department to say the least. It's probably more "powerful" than Mise's tasks. However, Mise's combination of really good — not astounding, but really good — task runners plus all the tool management stuff is unbeatable for the things I work on.
Just has a lot of UI/UX improvements over Make, like a way to list available recipes, convenient ways to define command-line parameters to recipes, consistent and easy syntax, and a whole lot of predefined functions and variables to cover common use cases like finding the number of CPUs on the current system, manipulate strings, etc. It doesn't do things that Make can't do, because Make can do anything a shell script can if you don't mind wrestling it into submission. It just does those things much more easily.
But it still has a few warts. Recipes look a lot like a shell script, but they're evaluated separately line-by-line, so you can't set a variable on one line and then read it in another. There are workarounds, but that's the default behavior. And a lot of the time when I'd want a task runner, I also want an environment manager (like uv or cargo or node/npm), so bundling those together matches my workflow better than managing those separately.
I have zero bad to say about Just. It's freaking awesome. If Mise disappeared, I'd go back to using Just. I just prefer Mise right now.
Make and Bazel already exist. Just and Mise and other options don’t need to reinvent that wheel. My last employer used Bazel and I liked using Mise as a wrapper around it so that `mise test` invoked the complex command line to run all the tests, kind of like a set of shell aliases that only affect that one repo.
Simply because for most developers it was faster to just whip up a bash script than to modify the Makefile and understand why their change did not do what they expected it to do. Hell, i've been dabbling in Makefiles for at least 25 years and still have to look up the weird mapping expressions when for some reason there's the "nothing to be done" or "No rule to make target `xxx'".
Its only killer feature is that it's everywhere, ready to be used by any brand new developer without any work. While "Mise", Just or many of the other replacements need stuff installed and/or setup.
they're literally just bash scripts so you don't need mise to run them. I've heard several users have setups where they have people with and without mise running them.
And until recently-ish, there wasn’t a great alternative that let end users run the equivalent of `make build && make test`, but without using Make. That’s why so many people abused it so: it seemed so close to being handy and convenient. And then someone comes along and runs `touch test` and `make test` doesn’t run tests anymore because no one knew they had to label that target as PHONY.
That’s the kind of stuff that got me all-in on Just from the beginning. It “feels” kind of like Make in the nice ways, but optimized for scripting instead of for building C projects. What a breath of fresh air! And as mentioned elsewhere, for me, Mise came along right behind it and gave us do-everything tool that’s nearly ideal for the kinds of non-C projects I work on now in Rust, Python, and TypeScript.
Just is a task runner, doesn’t do file dependencies / “derived files”
Make is the exact opposite. It’s completely based on files, and their derivatives.
Make will (well should) skip already compiled files, speeding up compilation if you’ve only changed 1 of 100000 file into ann object instead of waiting an hour, and go straight to linking.
Just is nice. But they are two different tools, that just happen to share the fact that they have some sort of dependency tree.
The tooling is 40 years old. It’s been long over due, but it’s ubiquitous.
Had been using make for simple tasks for ~8 years and just got tired of how limiting it is.
I feel it's significantly more practical than something like nix which feels like it has a steep learning curve.
e.g. `languages.rust.enable = true` and you're off to the races. You can add scripts, tasks, other packages, etc
I only have a few CLI/TUI programs installed with it, I try to keep it to a minimum. Just my editor, several language servers, AI tools and some other VM/container tooling. I haven't needed to break out of the happy path with it as of yet. I follow Nix progress with hopes of it eventually maturing into something better to use directly, but given the current state I prefer the wrappers at this point.
Sounds very interesting - I've been using just & docker (-compose) to manage my monorepo projects after a short frustrating stint with moon&proto. I like the simplicity of just, but onboarding can still be cumbersome, especially across platforms.
What do you put in it?
[hooks]
postinstall = [
"uv sync",
"ansible-galaxy role install -r ansible/requirements.yml",
"ansible-galaxy collection install -r ansible/requirements.yml",
]
I went looking for an issue to see if they're planning it, but the Mise repo doesn't have issues enabled? And no discussion on the README about why they don't. That doesn't inspire confidence.
If you're in a single-language npm monorepo, check out Wireit. It extends plain npm scripts to be able to have dependencies and caching (local and GitHub actions). It also has a unique service type of script for long-running tasks that lets you rebuild dependencies and no restart services.
If you specify sources but not "outputs" then mise will auto-track whether sources have been modified.
I requested the auto-track feature to speed up Docker builds a pretty long time ago, and it's been fantastic.
Ideally local and remote caching would be built on the same underlying code path.
I'm not sure when/why the issues were turned off. That's...surprising.
There used to be an issue that said the maintainers preferred discussions over issues. I'd link to it but it's a 404 now.
I've started a discussion regarding the lack of issues: https://github.com/jdx/mise/discussions/6566
Regarding confidence: I've used the project for a couple years now. I have a ton of confidence in it and I recommend it to everyone. While preferring discussions to issues is uncommon, the release frequency and utility of mise speak for itself. Take the time to look around the discussions and/or just use it. :)
There’s a couple exceptions to that boundary but in general that’s where mise stops.
https://mise.jdx.dev/roadmap.html#anti-goals
> Remote task caching - turbopack, moonrepo, and many others are trying to solve this (major) problem. mise's task runner will likely always just be a simple convenience around executing scripts.
I've had substantial frustration with multiple tools all trying to redo my PATH for me, usually to make themselves the first thing. It's to the point where I decided to give up and hard-code my PATH in my .zprofile and get rid of all of the various tools' init scripts so that I at least can clearly see and control which things are in which order and not having a bunch of scripts trying to rewrite it all the time all with slightly different algorithms.
Maybe it would work if mise could manage all "tools" (various programming languages) as well as "tools" (actual CLI applications written in one of the languages and usually installed with that languages manager, like `cargo install`, `go install`, `uv tool install`, etc), though then it seems like it might be a pain to switch over to.
it doesn't do this, you can even use shims with mise if you really want to
> Maybe it would work if mise could manage all "tools" (various programming languages) as well as "tools" (actual CLI applications written in one of the languages and usually installed with that languages manager, like `cargo install`, `go install`, `uv tool install`, etc), though then it seems like it might be a pain to switch over to.
it does do this
If you are a stickler about automation, easily repeatable system state, and being able to bootstrap new projects without having to eff around with the crap show of Ruby/Python/Node envs and how every person likes to use different tools for setting those up, or even just making it simple to have repeatable envs for go and rust, its great. Especially because you can do it without getting Docker/containerd involved.
Works great for getting a basic repeatable CI type build up and running without having to get CI or a big build system involved. Those are the right tools in the right situations, but for small teams or personal projects, I'm not going through the hassle and JVM dependencies of Bazel, Gradle, etc.
I also use it to manage my local system tools in my dotfiles (in combination with chezmoi).
This was the problem I wanted to solve, and I ended up on nix+direnv (and am considering devenv) because nix, due to the existence of nixos, packages all the tools already! Does Mise support zig? or nim? or crystal? Nix does! And Nix will continue to keep up to date with all the tools, whereas things like asdf and mise - since they're specialized and not the basis of a full distro - are less likely to do so.
It feels a little fragile to me to try to tackle so many concerns: if folks start relying on mise for more capabilities and one of them falls short, isn't as good as it could be, that could be a big hurt. There's definitely a nice conceptual win to having an all in one tool, but scoping up ambition feels risky.
Especially with task running, it feels like there's really so many very specific expert concerns that come into play. Being able to have a task graph & understanding the minimum work needed, being able to run only downstream tasks is a pretty important need, and that really gets into programming language specific views of what's happening. The idea of having something generic & so all is tempting but it feels impossible to get satisfactory results here.
Beyond Mise specifically, it's just interesting seeing the continuum between specific & multi-purpose tool, and seeing how software tends to scope itself up.
I would vastly rather have Mise shell out to Make etc for more complex DAG stuff. Those tools already exist and are good at their own specialties. Mise doesn't need to reinvent everything.
But I do think the new monorepo tasks are very on-brand for it. They don't seem so much as to add deep functionality as to provide a convention for finding and running other Mise files in a repo.
yeah, "fancy bash scripts" is a good way to think about tasks
I use mise and mostly like it. It has simplified my workflow for managing environments. But I don't need a task runner. `Make` and `just` already fulfill that purpose for me. I haven't used them in a monorepo, but both support importing and extending task/recipe files, so presumably it's possible to set them up appropriately. Maybe the UX wouldn't be as polished as a tool built for that use case, but I like my tools to "do one thing well". mise already does quite a lot as an environment manager, and I'd prefer it to remain focused on those problems.
Ah, you're the author. Thanks for all your work!
Is there any functionality in this release that might help with or be useful in features for sharing Mise config/tasks _across_ repos?
And do you have any thoughts on that idea in general?
Also I like having a global portable ~/.config/mise/config.toml file.
What I'm not sure yet is how to mix it with brew on Mac OS, so far what I do is, everything I can install with mise, I do, so I know it will work in linux as well, and everything else with brew.
There are exceptions like postgres, which seems available in the registry (asdf:mise-plugins/mise-postgres) but then you need to do:
brew install gcc readline zlib curl ossp-uuid icu4c pkg-config
My rule is, everything that doesn't have brew dependencies and is in mise registry or plugins, I install it from there, everything else from brew. But I'm curious, what's your approach ?
The creator of mise has written about it [1] but I don't think he switches from mac to linux:
> I tend to basically just use core plugins. I like mise for managing things where I really care about the major version (like node). If it's something like shfmt or jq I don't really care about the version. I just want the latest and for me, I find brew to be better suited to that purpose.
Also, I had a not-so-great experience with other builders/managers, including lerna so I love this.
@jdxcode, how long before I can replace Emacs with mise?
mise does 90% of what I need, but at only 1% of the hassle.
I like the idea of nix, and the future of building software is clearly something like it... I'm just not sure it'll be nix itself.
The solution here is: use Nix but don't use nix-darwin (at least not until you're generally comfortable with Nix for package management and dev shells). You do NOT have to use nix-darwin on Mac to reap 80% of the benefits of Nix (especially in a team setting).
After dropping nix-darwin, I think almost everyone will find that it's very easy to use Nix for sharing project setups with bespoke tooling. I just had a new team member onboard, knowing nothing about Nix, in a day or less, with several different languages and unusual tools.
Ahh, but I tried that too. I originally decided to play with nix-darwin because I was on a contract that used nix in their repos to ease onboarding of academic collaborators.
In practice, it was complicated enough that most of us ended up relying on the 2 nix experts to make any real changes, and when they left, the nix configs stagnated.
It might be the case that nix-darwin, and our particular python/ML repos, were "hard mode" for nix, but I truly think I gave it a fair shake.
If nix requires a lot of effort to do anything off the beaten path, it's just not the tool for me.
I use it because I want people to be able to get projects up and running quickly without having to comb through an outdated README, trying to deal with all of the different ways people like to install and use non-compiled languages, etc. Managing anything Node/Ruby/Python is all annoying.
Dela doesn't currently support mise as a source of tasks, but I will happily implement it if there is demand. Currently [1] I saw mise use on 94 out of 100,000 most starred github repos.
Thank you for allowing this moment of self promotion.
[0] https://github.com/aleyan/dela
[1] https://aleyan.com/blog/2025-task-runners-census/#most-used-...
Whenever I enter a repository for a node project the first thing I do is "npm run" to list the scripts. When I enter a repository with a Makefile I look at it. If I see make targets where both the target and dependencies are variables I exit the repository again real quick though.
You could probably use mise tools for moon builds, or proto with mise tasks too if you wanted to.
I've used Bazel a lot and contributed to it, but don't feel like it's adoptable by engineering teams <100 in size. mise might be an option though.
I don't think there exists a better solution for a project mixing Java and C/C++ than Bazel. The new module system for bazel has matured a lot. As an example, it's trivial to add boringssl and access it from Java.
mise tasks are basically just fancy bash scripts though, so I could totally see a setup that uses mise tasks/tools for node/js/ruby and dispatches to other tools for building Java and C/C++.
Not true, Taskfile supports inheritance of both itself and dotenvs. The main selling point of mice seems to be tamed multilang mixing. In case of pure-golang monorepos, mice seems like a lot of extra bloat.
For less developed / standardized platforms like py/node, it may come in handy. Of course it had to be written in rust…
Is it a well known convention for a monorepo root-relative path?
"we often need to run programs as side effect" => "scripts" => "task runner" => "make/just" => "mise"
and also why not docker or nix pros/cons etc
It especially makes life behind corporate barbed wires easier for me (YMMV).
My work env is pretty locked down as well... I've mostly relied on just using Deno+TS for shell scripts since it's relatively consistent for me across work and personal environments and the tooling can run from a user install. Though not using it to manage my tooling itself for work projects.
You can totally run non-JS/TS monorepos with turborepo. (But you need an additional package.json per module.)
(Note: I'm not saying it's better or worse than this.)
Mise has been great for me. What I like most is the ability to install tools globally with the npm, go and cargo backends, e.g. "mise use -g npm:prettier".
It's a simple thing but before, when I had to use something like nvm, I always had to remember which of the node versions I had installed global packages into.
I did recently have an issue where installing the newest node version actually installed the second newest one but that's a small thing.
Isn't running tasks in various folders kinda low hanging fruit for monorepo tasks? I've wanted a language/CI agnostic `monorepo-build-tool` build tool for a while, and getting something that allows for `monorepo-build-tool run-affected -- script/test` was one prompt to an LLM.
The bigger problem is caching and determining which projects need to be run when calling `run-affected`.
i even added some mise config lines to my global gitignore because i often use it in projects by others that don't set up mise config.
But it also allows me to control their versions in one spot, and present a unified task interface and dependency setup. E.g., I can make a testing task that runs playwright, but will depend on a python/java build task first.
Mise shines in polyglot systems.