[HN Gopher] Mise: Monorepo Tasks
___________________________________________________________________
Mise: Monorepo Tasks
Author : jdxcode
Score : 273 points
Date : 2025-10-06 14:07 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jdxcode wrote:
| 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 wrote:
| 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!
| banseljaj wrote:
| 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 wrote:
| I hope never! scope is big enough!
| zephraph wrote:
| 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 wrote:
| A mise postinstall hook?
|
| What do you put in it?
| paradox460 wrote:
| In the mise.toml
|
| https://mise.jdx.dev/hooks.html
| adamcharnock wrote:
| 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
| icedchai wrote:
| 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.
| efskap wrote:
| There's a tool that makes the Nix way a lot more approachable:
| https://devenv.sh/
|
| e.g. `languages.rust.enable = true` and you're off to the
| races. You can add scripts, tasks, other packages, etc
| eikenberry wrote:
| Another Nix based alternative.. https://flox.dev/
| jolux wrote:
| Having started with Mise, and now being primarily a Nix user
| -- Mise still has the edge for what it does. It supports
| pinning exact versions of many more languages than devenv
| does. When devenv doesn't support pinning the version you
| need, it's straight back to the pain and complexity of
| overlays and overrides and so on.
| chambored wrote:
| I've been using devenv for about 6 months now. I've started
| new projects with it and migrated old ones to use it as well.
| I've also set up my org's repositories with it. Onboarding
| devs to projects is simple. All everyone needs on their local
| machine is git, nix, and devenv. Bonus points for using it
| with direnv for automatic shell activation when you enter a
| directory. Direnv allows for IDE integrations as well for
| project dependencies.
| drcongo wrote:
| 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 wrote:
| I love mise so much and use it at $DAYJOB to manage a multi-
| service polyglot monorepo. Can't wait to try this.
| chanux wrote:
| 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 wrote:
| 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 wrote:
| As someone also behind corporate barbed wire and responsible
| for some build tools, I'm interested! What in particular makes
| life easier for you?
| arcticfox wrote:
| How does this compare to moon?
|
| https://github.com/moonrepo/moon
| jdxcode wrote:
| 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.
| ruined wrote:
| 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.
| thundergolfer wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/
| jdxcode wrote:
| 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 wrote:
| > 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. :)
| esafak wrote:
| 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.
| rsyring wrote:
| 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.
| spankalee wrote:
| That's remote caching. Local caching is still very important,
| and I guess it does support that.
| rsyring wrote:
| Thanks for the clarification. I don't use any tools that do
| remote caching so I guess I just glossed over that
| qualification. :o/
| quodlibetor wrote:
| Mise _does_ do local-only Make-similar task caching, if you
| specify sources and outputs: https://mise.jdx.dev/tasks/task-
| configuration.html#sources
|
| 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.
| jdxcode wrote:
| ah I think I misinterpreted this to mean remote caching
| quodlibetor wrote:
| yeah artifact caching is the obvious interpretation of
| caching when you're used to being compared to bazel, but
| the conversation was conflating "cache artifacts" and
| "cache should-run?" features.
| spankalee wrote:
| This is good to know! Seeing it say in the tool comparison
| that it doesn't support caching is a bit vague. I assumed
| that mean local caching too.
|
| Ideally local and remote caching would be built on the same
| underlying code path.
| elAhmo wrote:
| Speaking of task caching, this is what Mint/RWX does really
| great, just as you described - graph of dependencies and
| running only what has changed since the runs. Really helps
| speed up CI/CD tasks and lower the costs.
| jauntywundrkind wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| And that's the way I like it. heart_emoji.gif
| kstrauser wrote:
| 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 wrote:
| Just curious, as I am a fan of simple Makefiles, what benefits
| did you encounter moving from Make -> Just -> Mise?
| kstrauser wrote:
| 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.
| devnulled wrote:
| Taskfile is so much better. mise is what actually got me to
| start switching everything to Taskfile instead of Makefile as
| mise easily handles bootstrapping Taskfile and anything else
| you would need.
|
| Had been using make for simple tasks for ~8 years and just
| got tired of how limiting it is.
| Savageman wrote:
| Could you explain/share quickly how you combine mise and
| Taskfile?
| mapcars wrote:
| I always thought the idea of Makefiles is great, but the
| language is terrible and completely unintuitive to understand
| and learn.
| igor47 wrote:
| Yeah I love just, but getting the correct environment in a just
| task can be messy, even loading a virtualenv is annoying. I've
| also switched to mise for this reason
| jrop wrote:
| 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 wrote:
| 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.
| c-hendricks wrote:
| (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 wrote:
| 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 wrote:
| > 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 wrote:
| can't remember why I switched from asdf to mise, but I've had
| no problems with it in the last few years
| maleldil wrote:
| Startup time, maybe? I switched from pyenv to mise because it
| was adding significant time to my shell startup.
| aleyan wrote:
| 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
|
| [1] https://aleyan.com/blog/2025-task-runners-census/#most-
| used-...
| devnulled wrote:
| 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).
| sureglymop wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-06 23:00 UTC)