Introducing Monorepo Tasks #6564
Replies: 16 comments 37 replies
-
|
Does this support |
Beta Was this translation helpful? Give feedback.
-
|
Ah gotcha, ok just the string descriptors work everywhere, nice. |
Beta Was this translation helpful? Give feedback.
-
|
I can't say I've manually tested this but I remember designing it to support this |
Beta Was this translation helpful? Give feedback.
-
|
I think the major roadblock when I last tried mise as a task runner was that the task would run even if the dependency would fail. Has that been fixed? |
Beta Was this translation helpful? Give feedback.
-
|
it would be surprising to me if that were the case |
Beta Was this translation helpful? Give feedback.
-
|
It was filed under https://github.com/jdx/mise/issues/2530 which no longer exists because issues were deprecated in favor of Discussions. The title of the bug was |
Beta Was this translation helpful? Give feedback.
-
|
Excited to see this! We're currently using turbo in a mixed Rust/wasm/TS/Python/Go repo, and it's been a bit of a mixed bag (admittedly, I don't know how much of that is because we're unwilling to invest effort into modelling task inputs/outputs correctly in turbo). Compounding the issue is that what we really want a whole bunch of things out of it:
Absent these, I don't really see us adopting this anytime soon unfortunately. |
Beta Was this translation helpful? Give feedback.
-
|
+1 on DAG tasks (like my previous comment), and hot reload (triggered restarts). A mix of persistent tasks and non-persistent tasks, mixed in with dependencies, is critical. This is all language agnostic and also not necessarily hermetic or even related to caching. This is just about running and restarting tasks based on "triggers". (reusing turborepo terminology)
Here's an example usecase, running some kind of
|
Beta Was this translation helpful? Give feedback.
-
+1. I have been using mise for deps and Taskfile for tasks together a lot lately in projects where I don't want to drag a bunch of build and platform dependencies in to get something working. I have gotten tired of Makefiles and Taskfile is so much better. They work great together for setting up repeatable builds that aren't tied to a particular flavor of CI platform or build/monorepo tool. As far as tasks go, I think Taskfile is a lot more advanced and can cover most everything mise task does other than autodiscovery of tasks in other parts of a directory tree. To me that is one of the few things missing that I can think of; it's pretty great. No shade towards mise intended, I love mise for managing deps and glad to see tasks getting better, too. That said, I think something that would help mise with a proper DAG for tasks and task caching type issues would be for mise to implement something similar to what Taskfile has for being able to configure mise tasks to skip over tasks in various ways: |
Beta Was this translation helpful? Give feedback.
-
|
I think it's likely that some of the ways dependencies work with sources/outputs aren't quite right. What would be extremely helpful for me is if people were able to contribute failing e2e test to demonstrate where mise isn't behaving right—that's often the hard part for me of translating requirements to tests. Usually the implementation is the easy part. I think we could probably get some form of hot reloading too. The current solution is a bit naive since it just relies on watchexec and a single task but I could see us adding the ability to have watch configuration as part of the task definition which would allow for this sort of thing. I imagine I would either need to more deeply integrate with watchexec or take direct control of the file watching through fsmonitor but I think it could be done. Really though a lot of this I will admit isn't a primary goal of mine. I have always thought of mise tasks as more of a simple way to launch things and less of a full-fledged build system. Doesn't mean it can't grow into that (I don't think it's that far off today) but my focus is definitely more on things like getting usage to work better and the DX around simple runs. |
Beta Was this translation helpful? Give feedback.
-
Totally understand that for sure. That's sort of how I started with Makefiles as well, more of a taskrunner / self-documenting way to handle various tasks in a software project. I am a fan of simple focused tools and that's how I had always thought of tasks in mise as well. I eventually moved to Taskfile because the syntax is so similar yet way less annoying, and its easy to install and use in a project just like mise is. 😃 I think a monorepo is an overloaded term and means different things to different people. It can be everything from a single service which has separated out some of its libraries/apis that other projects could consume, all the way up to everyone in a company of 20,000+ engineers has to use the same git repo and play in the same system of build & deploy pipelines, etc. But IMHO, once you get to even a simple monorepo that has a web app, mobile app, and a service with an api that they both depend on, you start getting into the territory of needing a DAG, cached/failed tasks, etc. E.g, the web app could be Node, the mobile in Kotlin Native, and backend in Kotlin/Go/Rust/whatever, pretty much at a state of needing a DAG. Anyway, I really enjoy mise and not trying to be negative. 😃 I use mise tasks sparingly and just trying to help. More along the lines that monorepos easily get complicated and you'l probably have to go down a path of a DAG with tasks because users will keep bolting on use cases that essentially require one. Just something to keep in mind as you move tasks forward. |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
I don't think there's any question this is the most popular syntax for monorepo build systems. I'm not going to quibble on whether that makes it a standard but I also don't think it could be considered a mistake to go with the flow here. |
Beta Was this translation helpful? Give feedback.
-
I'm having trouble running |
Beta Was this translation helpful? Give feedback.
-
My bias is more on the frontend/javascript tooling side of the things and for me I can say that I never saw similar syntax for task runners in monorepo systems, nx, turborepo, deno, bun, npm, pnpm, none of them use syntax like these *AFAIK. But maybe |
Beta Was this translation helpful? Give feedback.
-
|
that's because JS projects don't support any kind of hierarchy |
Beta Was this translation helpful? Give feedback.
-
|
Quick feedback: |
Beta Was this translation helpful? Give feedback.
-
|
I was playing around with tasks that trigger other tasks, but I can't get a project task to run when it's called from the root. If I have a task # file: projects/backend/mise.toml
[tasks.hello]
run = "echo 'hello world'"And in the root I have: # file: mise.toml
[tasks.hello]
run = [
{ task = "//projects/backend:hello" }
]Executing And for completeness: $ mise tasks --all
//:hello
//projects/backend:hello
$ mise run //projects/backend:hello
[//projects/backend:hello] $ echo 'hello world'
hello worldI've only started using Mise with tasks recently, so maybe I'm missing something. Otherwise, this feature looks like it's going to be really useful, so thank you. |
Beta Was this translation helpful? Give feedback.
-
|
Hitting the same issue, can confirm that having a root task that i.e. this in the root works, # file: mise.toml
[tasks.hello]
depends = ["//projects/backend:hello"]
run = "echo hello" |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Exciting! Been playing around a bit with this today and I really like the concept! One problem I ran into: Repo structure: For setups like this it would be great if the "sub projects" could independently define their tasks without being "aware" that they are also used in a monorepo context. This works to some degree for basic tasks since they are auto discovered as child tasks, but because task names in "local contexts" need to be My expectation would be that would be the same as With the current "local task" references having different syntax depending on monorepo-ness, I think it's impossible to get the above setup to work in both contexts - am I correct in that assumption? |
Beta Was this translation helpful? Give feedback.
-
|
this is an obvious gap, @hverlin was talking to me about it in discord. I think there's a few avenues. One would be to permit I think before I go to far I want to figure out what the long-term is for non-monorepo tasks here. I don't see the current syntax going away, but I could see us adopting some of the monorepo features such that you could do things like Non-monorepo will be harder to change since it's not experimental so we'd want to get the design right the first time, where with monorepo we have the liberty to change it however we want. |
Beta Was this translation helpful? Give feedback.
-
|
Bravo, mise continues to improve, it's one of my favorite tools (also when it was I migrated a multi-project to mono-repo, and I noticed this issue (or maybe it's expected):
To reproduce (minimal sample): .
├── mise.toml
└── submodule
└── mise.toml
min_version = "2025.10.6" # "2025.9.7"
experimental_monorepo_root = true
[settings]
experimental = true
[tasks.before]
run = "echo 'before'"
[tasks."do:item-1"]
depends = [":before"]
run = "echo 'do:item-1'"❯ mise run //submodule:do:item-1
mise ERROR task not found: :before
mise ERROR Run with --verbose or MISE_VERBOSE=1 for more informationMy current workaround is to replace |
Beta Was this translation helpful? Give feedback.
-
|
Yeah this should be working as you expect |
Beta Was this translation helpful? Give feedback.
-
|
It seems that monorepo tasks do not propagate Configuration Environments afaict. E.g: running It seems that the root (If anything is unclear, I can make a better reproduction if needed) Side note: it seems that Configuration Environments are a little unwieldy to use in real applications, is there a better way to do things like "run the PRODUCTION build + publish instead of STAGING, while switching out all the env vars" with all the same commands, or close to the same? |
Beta Was this translation helpful? Give feedback.
-
|
I have been getting ProjectA/mise.toml ProjectB/mise.toml running command:
|
Beta Was this translation helpful? Give feedback.
-
|
Same here, There seem to be some difference on how task label are interpreted for also for local dependents tasks, it is necessary to prefix it with |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I was able to fix it by adding the |
Beta Was this translation helpful? Give feedback.
-
|
I seem to be unable to test this functionnality I have the following setup: |
Beta Was this translation helpful? Give feedback.
-
|
I'm seeing something similar, in |
Beta Was this translation helpful? Give feedback.
-
|
seems fine to me. I think you're wanting to use |
Beta Was this translation helpful? Give feedback.
-
|
That was it, thank you. |
Beta Was this translation helpful? Give feedback.
-
|
@jdx - I believe the issue is with mise files that are stored in the I currently have I would imagine all possible paths listed here would function or is this a limitation? |
Beta Was this translation helpful? Give feedback.
-
|
sounds like a bug |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to use this feature on my Windows using pwsh. My project structure is as follows: Root experimental_monorepo_root = true
[env]
MISE_EXPERIMENTAL = true
[tasks.hello]
run = "//apps/...:hello"Sub-project [tasks.hello]
run = "echo 'hello from [backend|frontend]'"When I run: $ mise tasks
Name Description
//:hello And then: $ mise :hello
[//:hello] $ //apps/...:hello
The network path was not found.
[//:hello] ERROR task failed |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I figured it out — the issue was due to a misconfigured [tasks.hello]
run = "//apps/...:hello" # ❌ Incorrect
# Should be:
run = { task = "//apps/...:hello" } # ✅ Correct |
Beta Was this translation helpful? Give feedback.
-
|
Or use [tasks.hello]
depends = ["//apps/...:hello"]Use |
Beta Was this translation helpful? Give feedback.
-
|
it's just me or? monorepo tasks broken on 2025.10.18 macos-arm64 (2025-10-25) Show all tasks: Root mise.toml: Frontend mise toml: |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Unless mistaken, tasks are still inherited in monorepo mode. However, I would expect to see At the moment, the following does not work |
Beta Was this translation helpful? Give feedback.
-
|
For some reason, adding [env]
MISE_EXPERIMENTAL = trueto each Any explanations/workarounds? |
Beta Was this translation helpful? Give feedback.
-
experimental_monorepo_root = true
[env]
MISE_EXPERIMENTAL = true...works for me in version 2025.11.6 You have mise activated? If you set other env vars along side that one are they present in your shell? |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to "activate" anything?...I could as well just define Then I want to define something like: and just run My understanding is that supposed to do exactly that. |
Beta Was this translation helpful? Give feedback.
-
|
Shell integration via activation is needed to set env vars in the calling shell environment. The mise binary needs to read the env var from its environment not from its config. In your case you will need to set the env var in the calling environment for monorepos to work until it is no long an experimental feature. Env vars in the mise file will only be available to command it runs. |
Beta Was this translation helpful? Give feedback.
-
|
I've been try to use default tasks in monorepo, but when I either set Another minor issues I've found is |
Beta Was this translation helpful? Give feedback.
-
|
I think my search for defining the default shell for mise tasks fits best in this discussion. Q: Is there a way to define the default shell for all tasks? File: experimental_monorepo_root = true
[env]
[tasks]
shell = 'zsh -ic'
[tasks.build]
# shell = 'zsh -ic'
depends = ['//webui:build']
description = "Build Ansible Lint Reporter"
run = [
'pip install -e .',
#
] |
Beta Was this translation helpful? Give feedback.
-
|
It is even possible to preload a shell environment in all tasks: It would be nice to have an environment variable like |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
-
We're excited to announce Monorepo Tasks, a powerful new feature that brings first-class monorepo support to mise tasks! 🚀
What is it?
Monorepo Tasks allows you to manage tasks across multiple projects in a single repository, with each project maintaining its own tools, environment variables, and tasks. Think of it as bringing the power of tools like Bazel or Turborepo to mise's task system, but with mise's signature simplicity.
Key Features
🎯 Unified Task Namespace
All tasks across your monorepo are automatically discovered and prefixed with their location:
🌳 Smart Tool & Environment Inheritance
Define common tools at the root, override them where needed:
🎭 Powerful Wildcard Patterns
Run tasks across multiple projects with ease:
✨ Consistent Execution Anywhere
Run tasks from anywhere in the monorepo - they always execute with the correct context, tools, and environment from their config_root.
🔒 Automatic Trust Propagation
Trust your monorepo root once, and all descendant configs are automatically trusted.
Quick Start
1. Enable the feature in your root
mise.toml:2. Set the experimental flag:
export MISE_EXPERIMENTAL=13. Add tasks to your projects:
4. Run tasks from anywhere:
mise //projects/frontend:build mise //...:test # Run tests in all projects!Example Monorepo Structure
Run all service builds:
mise //services/...:buildRun all app tests:
mise //apps/...:testRun everything:
mise '//...:*'(if you're brave! 😄)Why This Matters
Managing monorepos is hard. Coordinating tools, tasks, and environments across dozens of projects is even harder. With Monorepo Tasks, you get:
How Does This Compare to Other Tools?
The monorepo ecosystem is rich with excellent tools, each with different strengths. Here's how mise's Monorepo Tasks compares:
Simple Task Runners
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.
mise's advantage: Automatic task discovery across the entire monorepo with a unified namespace and powerful wildcard patterns.
JavaScript-Focused Tools
Nx, Turborepo, and Lerna are powerful tools specifically designed for JavaScript/TypeScript monorepos.
mise's advantage: Language-agnostic support. While these tools excel in JS/TS ecosystems, mise works equally well with Rust, Go, Python, Ruby, or any mix of languages. You also get unified tool version management (not just tasks) and environment variables across your entire stack.
Large-Scale Build Systems
Bazel (Google) and Buck2 (Meta) are industrial-strength build systems designed for massive, multi-language monorepos at companies with thousands of engineers.
Both are extremely powerful but come with significant complexity:
mise's advantage: Simplicity through non-hermetic builds. mise doesn't try to control your entire build environment in isolation - instead, it manages tools and tasks in a flexible, practical way. This "non-hermetic" approach means you can use mise without restructuring your entire codebase or learning a new language. You get powerful monorepo task management with simple TOML configuration - enough power for most teams without the enterprise-level complexity that hermetic builds require.
Other Notable Tools
Rush (Microsoft) offers strict dependency management and build orchestration for JavaScript monorepos, with a focus on safety and convention adherence.
Moon is a newer Rust-based build system that aims to be developer-friendly while supporting multiple languages.
The mise Sweet Spot
mise's Monorepo Tasks aims to hit the sweet spot between simplicity and power:
When to choose mise:
When to consider alternatives:
The best tool is the one that fits your team's needs. mise's Monorepo Tasks is designed for teams who want powerful monorepo management without the complexity overhead, especially when working across multiple languages.
Try It Out!
This feature is experimental, which means:
Read the full documentation: Monorepo Tasks Guide
We Want Your Feedback!
Please try it out and let us know:
Share your experience in the comments below! 👇
Special shoutout to the mise community for the feedback and ideas that led to this feature. Happy building! 🛠️
Beta Was this translation helpful? Give feedback.
All reactions