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.
Not caching tasks is kind of a huge missing feature. Once you can describe a graph of tasks with dependencies, not running already clean dependencies is how you make that tractable for repeated runs even in moderate-sized monorepos.
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.
> 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 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.
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.
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. :)
You are asking mise to become a build system like bazel.
I suppose it already is one, in a sense. Caching is a useful feature but mise needs to guard against increasing complexity.
Perhaps it could integrate with builds tools.
I'm really bullish on mise as a tool. It's quickly become one of my goto tools when starting a new project. Being able to have one config file to manage tools (node, python, rust, go, etc) as well as a simple makefile replacement makes it incredibly convenient. I pretty much always setup a `postinstall` hook so all someone has to do is `mise install` one of my projects and they'll get all the correct tool versions as well as having dependencies installed (like running `npm install`) automatically.
I feel it's significantly more practical than something like nix which feels like it has a steep learning curve.
Mise is a hard sell for me when I can have pure Nix-shells. However, I can see this gaining wider adoption since it's learning curve is so much lower than Nix.
For quite some time, I have gathered this set of Rust CLI tasks that are exactly the same. I have used them as template generators for cargo-generate. This became a problem recently when I was writing a monorepo that had mixed projects (Rust server, Svelte Frontend, and Terraform deployment). This comes at just the right time for me to utilize this without going insane.
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?
I'm really excited about this. I think it blends the both worlds of simple task runners like just/taskfile while also having a lot of the power of tools like bazel/buck2. Excited to hear about what people build!
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.
I’m not super familiar with moon, but I think it’d be fair to say mise started out solving the tool problem where moon solved the build problem first. I’d expect both to be more fleshed out than the other in both departments.
You could probably use mise tools for moon builds, or proto with mise tasks too if you wanted to.
I've used bazel for about 10 years, all in small orgs. Right now, single digit team.
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.
This is fair. mise (by design) does nothing to help with that sort of thing. It's also definitely designed for languages outside C/C++, and to a lesser degree 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++.
I was a bit slow to hop on mise because it took me while understand it (Likely because I entered thinking of it as a direnv replacement with more features).
It especially makes life behind corporate barbed wires easier for me (YMMV).
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`.
Kind of interesting seeing mise grow and grow. Others have noted they encountered it first as a direnv replacement. At my last job it was an asdf tool-installer replacement. It's also a task and now mono-repo task runner.
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'd counter that I actively don't want those more powerful features. Like, I get why anyone would want them, but right now Mise is "knowable". I can sit down with its doc site and figure out any of its features without building a strong mental model of their underlying implementation. And that also means my coworkers aren't as likely to abuse and twist it into the kinds of things people have used tools like Make for.
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.
> 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
Mise has become almost indispensable for me within just a few months, I've rebuilt so much of our tooling around it. If anyone else finds it as integral to their work I'd like to encourage them to also sponsor it.
This is beautiful! Thank you so much!
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.
Not caching tasks is kind of a huge missing feature. Once you can describe a graph of tasks with dependencies, not running already clean dependencies is how you make that tractable for repeated runs even in moderate-sized monorepos.
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.
https://github.com/google/wireit/
Turns out caching tasks is an anti-goal:
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’d argue it’s mise’s indifference to project source code and library dependencies that gives it the simplicity worth using.
There’s a couple exceptions to that boundary but in general that’s where mise stops.
> 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.
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. :)
You are asking mise to become a build system like bazel. I suppose it already is one, in a sense. Caching is a useful feature but mise needs to guard against increasing complexity. Perhaps it could integrate with builds tools.
I'm really bullish on mise as a tool. It's quickly become one of my goto tools when starting a new project. Being able to have one config file to manage tools (node, python, rust, go, etc) as well as a simple makefile replacement makes it incredibly convenient. I pretty much always setup a `postinstall` hook so all someone has to do is `mise install` one of my projects and they'll get all the correct tool versions as well as having dependencies installed (like running `npm install`) automatically.
I feel it's significantly more practical than something like nix which feels like it has a steep learning curve.
A mise postinstall hook?
What do you put in it?
Mise is a hard sell for me when I can have pure Nix-shells. However, I can see this gaining wider adoption since it's learning curve is so much lower than Nix.
For quite some time, I have gathered this set of Rust CLI tasks that are exactly the same. I have used them as template generators for cargo-generate. This became a problem recently when I was writing a monorepo that had mixed projects (Rust server, Svelte Frontend, and Terraform deployment). This comes at just the right time for me to utilize this without going insane.
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?
I hope never! scope is big enough!
I'm really excited about this. I think it blends the both worlds of simple task runners like just/taskfile while also having a lot of the power of tools like bazel/buck2. Excited to hear about what people build!
I don't know, I'm torn about it.
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!
How does this compare to moon?
https://github.com/moonrepo/moon
I’m not super familiar with moon, but I think it’d be fair to say mise started out solving the tool problem where moon solved the build problem first. I’d expect both to be more fleshed out than the other in both departments.
You could probably use mise tools for moon builds, or proto with mise tasks too if you wanted to.
Can someone with both Bazel and mise experience comment on whether mise fulfils its promise of being a "sweet spot" between Bazel and anarchy?
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've used bazel for about 10 years, all in small orgs. Right now, single digit team.
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.
This is fair. mise (by design) does nothing to help with that sort of thing. It's also definitely designed for languages outside C/C++, and to a lesser degree 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++.
I was a bit slow to hop on mise because it took me while understand it (Likely because I entered thinking of it as a direnv replacement with more features).
It especially makes life behind corporate barbed wires easier for me (YMMV).
i will just add another comment appreciating mise.
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.
I love mise so much and use it at $DAYJOB to manage a multi-service polyglot monorepo. Can't wait to try this.
(no offense, I'm probably missing something)
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`.
Kind of interesting seeing mise grow and grow. Others have noted they encountered it first as a direnv replacement. At my last job it was an asdf tool-installer replacement. It's also a task and now mono-repo task runner.
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'd counter that I actively don't want those more powerful features. Like, I get why anyone would want them, but right now Mise is "knowable". I can sit down with its doc site and figure out any of its features without building a strong mental model of their underlying implementation. And that also means my coworkers aren't as likely to abuse and twist it into the kinds of things people have used tools like Make for.
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.
> 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
And that's the way I like it. heart_emoji.gif
Mise has become almost indispensable for me within just a few months, I've rebuilt so much of our tooling around it. If anyone else finds it as integral to their work I'd like to encourage them to also sponsor it.