9 ms·

Mise: Monorepo Tasks

379 points by jdxcode 1y ago

hk1337 1y ago
I’m just now learning about mise tasks, this is amazing!
jdxcode 1y ago
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!
- imiric 1y ago
  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!
- horse666 1y ago
  Nice work @jdxcode, this looks great. 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? https://github.com/jdx/mise/discussions/4562 https://github.com/jdx/mise/discussions/4562
  - jdxcode 1y ago
    I don't, sorry
    - horse666 1y ago
      No worries, thanks!
banseljaj 1y ago
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?
- jdxcode 1y ago
  I hope never! scope is big enough!
zephraph 1y ago
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.
- blackhaj7 1y ago
  A mise postinstall hook? What do you put in it?
  - paradox460 1y ago
    In the mise.toml https://mise.jdx.dev/hooks.html https://mise.jdx.dev/hooks.html
  - adamcharnock 1y ago
    An example from one of our monorepo's ansible directories: [hooks] postinstall = [ "uv sync", "ansible-galaxy role install -r ansible/requirements.yml", "ansible-galaxy collection install -r ansible/requirements.yml", ] So following a `mise install`, the user also gets all the needed python packages installed via uv, and also all the galaxy roles/collections installed
    - blackhaj7 1y ago
      Love it - great idea
- icedchai 1y ago
  yes! I set up a new project with mise. It makes it so much easier for new people to get started without having to do a bunch of manual steps. Awesome tool.
- 1y ago
drcongo 1y ago
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.
alexjplant 1y ago
I love mise so much and use it at $DAYJOB to manage a multi-service polyglot monorepo. Can't wait to try this.
chanux 1y ago
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).
- tracker1 1y ago
  Nice to hear this input... My first glance, I didn't really notice that Windows was supported, and it looks like there's support for dotnet as well... so may give it a try in the near future. 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.
- amcvitty 1y ago
  As someone also behind corporate barbed wire and responsible for some build tools, I’m interested! What in particular makes life easier for you?
  - chanux 1y ago
    I have replaced manual (and tedious) download binary from Github releases and install workflows. Also switched from pyenv to mise for Python which I feel is an improvement in the experience.
ruined 1y ago
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.
arcticfox 1y ago
How does this compare to moon? https://github.com/moonrepo/moon https://github.com/moonrepo/moon
- deleted 1y ago
  [deleted]
- jdxcode 1y ago
  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.
thundergolfer 1y ago
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.
- gorset 1y ago
  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.
  - jdxcode 1y ago
    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++.
spankalee 1y ago
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/ https://github.com/google/wireit/
- jdxcode 1y ago
  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.
- rsyring 1y ago
  > 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 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. :)
- esafak 1y ago
  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.
jauntywundrkind 1y ago
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.
- kstrauser 1y ago
  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.
  - jdxcode 1y ago
    > 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
kstrauser 1y ago
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.
- elAhmo 1y ago
  Just curious, as I am a fan of simple Makefiles, what benefits did you encounter moving from Make -> Just -> Mise?
  - kstrauser 1y ago
    The biggest jump was from Make -> Just. Just -> Mise was minor in comparison, although enough to persuade me. 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.
    - 1y ago
jrop 1y ago
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.
- devnulled 1y ago
  If you think of it more of in the context of making it easy for people other than you and your bespoke machine to bootstrap a project, that's where it really shines. The toml config is very simple for people to understand. 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.
- KingMob 1y ago
  I tried nix-darwin for a year, eventually declared nix bankruptcy, and settled on 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.
  - felixyz 1y ago
    I've seen several Mac users have the same experience: going all-in on nix-darwin and then getting frustrated. But nix-darwin is one of the worst ways of getting into Nix, because its goal is to make your whole macOS system configurable with Nix, but macOS is a moving target and (unlike Linux) not built to be modular at all. I know people put a lot of hard work into nix-darwin, but it's simply not the main focus of Nix as a whole and sadly it might not ever become a seamless experience. (I'm not a mac user so not keeping up, but I do see colleagues trying it out from time to time.) 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.
c-hendricks 1y ago
(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`.
ufmace 1y ago
Mise seems pretty cool, but the thing that makes me reluctant to get on board now (current asdf user) is that it seems to want to manage too much. Especially with regard to using PATH munging. 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.
- jdxcode 1y ago
  > I've had substantial frustration with multiple tools all trying to redo my PATH for me, usually to make themselves the first thing. 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
- zem 1y ago
  can't remember why I switched from asdf to mise, but I've had no problems with it in the last few years
  - maleldil 1y ago
    Startup time, maybe? I switched from pyenv to mise because it was adding significant time to my shell startup.
    - zem 1y ago
aleyan 1y ago
If you want to get a single entry point into your repo's task, also consider my tool: dela[0]. It scans a variety of task file definitions like pyproject.toml, package.json, makefile, etc and makes them available on the cli via the bare name of the task. It has been very convenient for me so far on diverse repos, and the best part is that I didn't have to convince anyone else working on the repos to adjust the repos structure. 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 https://github.com/aleyan/dela [1] https://aleyan.com/blog/2025-task-runners-census/#most-used-task-runners https://aleyan.com/blog/2025-task-runners-census/#most-used-...
- sureglymop 1y ago
  Sounds great but does it support listing all tasks? 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.
devnulled 1y ago
Mise is the best. 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).
- jbverschoor 1y ago
  If you want to run al these possible supplychain attacks onto your host machine, be my guest.
- pjz 1y ago
  >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 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.
sureglymop 1y ago
This is awesome! Just the other day I was thinking it would be nice if mise had something like 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.
clickety_clack 1y ago
Does mise overlap with uv for python?
- KingMob 1y ago
  To some extent, yes, but you can have mise defer to uv for the python side. I have mise using uv, npm, clojure, and java, and it defers to all their packaging systems. 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.
Garlef 1y ago
I think their comparison table is a bit incorrect: 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.)
thingortwo 1y ago
I recently moved from just to mise. Just is great but it is only a command runner and I needed mise other features and I'm glad I made the switch. I just wish docs would improve a little in structure and explanation of usecases/history while drawing comparison with other things like nix,docker etc as a newbie it helps to know the why like: "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
alfonsodev 1y ago
For me, because I jump from project to project, different versions and languages, is just perfect to use the same mise commands, and I know it's going to work. 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. - [1] https://mise.jdx.dev/how-i-use-mise.html https://mise.jdx.dev/how-i-use-mise.html
- c-hendricks 1y ago
  I follow what you've quoted at the end of your post. I only use mise for things I need multiple versions of.
frou_dh 1y ago
IMHO the document's introduction should explain why this double-slash // syntax is being used. It may be obvious to some readers, but not to me. Is it a well known convention for a monorepo root-relative path?
pancsta 1y ago
> Taskfile and Just are fantastic for single-project task automation. They're lightweight and easy to set up, but they weren't designed with monorepos in mind. While you can have multiple Taskfiles/Justfiles in a repo, they don't provide unified task discovery, cross-project wildcards, or automatic tool/environment inheritance across projects. 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…
jtolj 1y ago
I'm a bit late to this thread, but also wanted to express my thanks to Jeff for mise. I have a lot of different projects in my ~ directory in various languages and with various task runners. Migrating dependency management and wrapping tasks in mise's task runner has removed so much cognitive overhead getting spun back up on projects I haven't touched in a while. Great work!
- bin_bash 1y ago
  glad to hear! I got more flak than praise when I launched tasks 2 years ago since people didn't want mise to get too complex but I'm glad I stuck with my guns and pushed it anyways. I thought bringing tasks and tools together made a lot of sense and I'm glad you're seeing the value of it

379 points by jdxcode 1y ago

I’m just now learning about mise tasks, this is amazing!

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!

imiric 1y ago
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!
horse666 1y ago
Nice work @jdxcode, this looks great. 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? https://github.com/jdx/mise/discussions/4562 https://github.com/jdx/mise/discussions/4562
- jdxcode 1y ago
  I don't, sorry
  - horse666 1y ago
    No worries, thanks!

banseljaj 1y ago

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?

jdxcode 1y ago
I hope never! scope is big enough!

zephraph 1y ago

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.

blackhaj7 1y ago
A mise postinstall hook? What do you put in it?
- paradox460 1y ago
  In the mise.toml https://mise.jdx.dev/hooks.html https://mise.jdx.dev/hooks.html
- adamcharnock 1y ago
  An example from one of our monorepo's ansible directories: [hooks] postinstall = [ "uv sync", "ansible-galaxy role install -r ansible/requirements.yml", "ansible-galaxy collection install -r ansible/requirements.yml", ] So following a `mise install`, the user also gets all the needed python packages installed via uv, and also all the galaxy roles/collections installed
  - blackhaj7 1y ago
    Love it - great idea
icedchai 1y ago
yes! I set up a new project with mise. It makes it so much easier for new people to get started without having to do a bunch of manual steps. Awesome tool.
1y ago

drcongo 1y ago

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.

alexjplant 1y ago

I love mise so much and use it at $DAYJOB to manage a multi-service polyglot monorepo. Can't wait to try this.

chanux 1y ago

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).

tracker1 1y ago
Nice to hear this input... My first glance, I didn't really notice that Windows was supported, and it looks like there's support for dotnet as well... so may give it a try in the near future. 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.
amcvitty 1y ago
As someone also behind corporate barbed wire and responsible for some build tools, I’m interested! What in particular makes life easier for you?
- chanux 1y ago
  I have replaced manual (and tedious) download binary from Github releases and install workflows. Also switched from pyenv to mise for Python which I feel is an improvement in the experience.

ruined 1y ago

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.

arcticfox 1y ago

How does this compare to moon? https://github.com/moonrepo/moon https://github.com/moonrepo/moon

deleted 1y ago
[deleted]
jdxcode 1y ago
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.

thundergolfer 1y ago

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.

gorset 1y ago
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.
- jdxcode 1y ago
  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++.

spankalee 1y ago

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/ https://github.com/google/wireit/

jdxcode 1y ago
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.
rsyring 1y ago
> 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 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. :)
esafak 1y ago
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.

jauntywundrkind 1y ago

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.

kstrauser 1y ago
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.
- jdxcode 1y ago
  > 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

kstrauser 1y ago

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.

elAhmo 1y ago
Just curious, as I am a fan of simple Makefiles, what benefits did you encounter moving from Make -> Just -> Mise?
- kstrauser 1y ago
  The biggest jump was from Make -> Just. Just -> Mise was minor in comparison, although enough to persuade me. 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.
  - 1y ago

jrop 1y ago

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.

devnulled 1y ago
If you think of it more of in the context of making it easy for people other than you and your bespoke machine to bootstrap a project, that's where it really shines. The toml config is very simple for people to understand. 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.
KingMob 1y ago
I tried nix-darwin for a year, eventually declared nix bankruptcy, and settled on 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.
- felixyz 1y ago
  I've seen several Mac users have the same experience: going all-in on nix-darwin and then getting frustrated. But nix-darwin is one of the worst ways of getting into Nix, because its goal is to make your whole macOS system configurable with Nix, but macOS is a moving target and (unlike Linux) not built to be modular at all. I know people put a lot of hard work into nix-darwin, but it's simply not the main focus of Nix as a whole and sadly it might not ever become a seamless experience. (I'm not a mac user so not keeping up, but I do see colleagues trying it out from time to time.) 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.

c-hendricks 1y ago

(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`.

ufmace 1y ago

Mise seems pretty cool, but the thing that makes me reluctant to get on board now (current asdf user) is that it seems to want to manage too much. Especially with regard to using PATH munging. 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.

jdxcode 1y ago
> I've had substantial frustration with multiple tools all trying to redo my PATH for me, usually to make themselves the first thing. 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
zem 1y ago
can't remember why I switched from asdf to mise, but I've had no problems with it in the last few years
- maleldil 1y ago
  Startup time, maybe? I switched from pyenv to mise because it was adding significant time to my shell startup.
  - zem 1y ago

aleyan 1y ago

If you want to get a single entry point into your repo's task, also consider my tool: dela[0]. It scans a variety of task file definitions like pyproject.toml, package.json, makefile, etc and makes them available on the cli via the bare name of the task. It has been very convenient for me so far on diverse repos, and the best part is that I didn't have to convince anyone else working on the repos to adjust the repos structure. 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 https://github.com/aleyan/dela [1] https://aleyan.com/blog/2025-task-runners-census/#most-used-task-runners https://aleyan.com/blog/2025-task-runners-census/#most-used-...

sureglymop 1y ago
Sounds great but does it support listing all tasks? 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.

devnulled 1y ago

Mise is the best. 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).

jbverschoor 1y ago
If you want to run al these possible supplychain attacks onto your host machine, be my guest.
pjz 1y ago
>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 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.

sureglymop 1y ago

This is awesome! Just the other day I was thinking it would be nice if mise had something like 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.

clickety_clack 1y ago

Does mise overlap with uv for python?

KingMob 1y ago
To some extent, yes, but you can have mise defer to uv for the python side. I have mise using uv, npm, clojure, and java, and it defers to all their packaging systems. 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.

Garlef 1y ago

I think their comparison table is a bit incorrect: 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.)

thingortwo 1y ago

I recently moved from just to mise. Just is great but it is only a command runner and I needed mise other features and I'm glad I made the switch. I just wish docs would improve a little in structure and explanation of usecases/history while drawing comparison with other things like nix,docker etc as a newbie it helps to know the why like: "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

alfonsodev 1y ago

For me, because I jump from project to project, different versions and languages, is just perfect to use the same mise commands, and I know it's going to work. 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. - [1] https://mise.jdx.dev/how-i-use-mise.html https://mise.jdx.dev/how-i-use-mise.html

c-hendricks 1y ago
I follow what you've quoted at the end of your post. I only use mise for things I need multiple versions of.

frou_dh 1y ago

IMHO the document's introduction should explain why this double-slash // syntax is being used. It may be obvious to some readers, but not to me. Is it a well known convention for a monorepo root-relative path?

pancsta 1y ago

> Taskfile and Just are fantastic for single-project task automation. They're lightweight and easy to set up, but they weren't designed with monorepos in mind. While you can have multiple Taskfiles/Justfiles in a repo, they don't provide unified task discovery, cross-project wildcards, or automatic tool/environment inheritance across projects. 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…

jtolj 1y ago

I'm a bit late to this thread, but also wanted to express my thanks to Jeff for mise. I have a lot of different projects in my ~ directory in various languages and with various task runners. Migrating dependency management and wrapping tasks in mise's task runner has removed so much cognitive overhead getting spun back up on projects I haven't touched in a while. Great work!

bin_bash 1y ago
glad to hear! I got more flak than praise when I launched tasks 2 years ago since people didn't want mise to get too complex but I'm glad I stuck with my guns and pushed it anyways. I thought bringing tasks and tools together made a lot of sense and I'm glad you're seeing the value of it