Introducing Monorepo Tasks #6564
Replies: 29 comments 103 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.
-
I am going to second this. I have just started using mise in anger and it will be replacing my use of asdf for personal projects and work projects will take a bit longer given I will need to ensure stuff keeps working for all team members. Taskfile is a harder sell for quite a few repos because we already have an advanced set of common tasks that are composed in sub-project 'task.yml' files (using
This is my main sticking point for Pulumi IaC monorepo projects, in particular programatic checks which allow us to check the login status of the user automatically for This combined with source checks which mise already supports for forcing |
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.
-
|
this has been released. https://github.com/jdx/mise/releases/tag/v2026.1.3 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @chadxz. I will give it a try with the latest release. |
Beta Was this translation helpful? Give feedback.
-
|
Posted this PR describing possible solutions for the inherited task working directory issue. Would be interested in your thoughts @PierreKiwi on what would be most intuitive to you. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @chadxz, mise tasks --all
Name Description
//:taskDefinedAtRoot
//example-pkg:build
//example-pkg:deploy Deploy application to cloud
//example-pkg:taskDefinedAtRoot
//libs/example-lib1:build
//libs/example-lib1:taskDefinedAtRoot
//libs/example-lib2:build
//libs/example-lib2:taskDefinedAtRootRegarding your comment about the execution directory. Indeed, that's the next problem on the list. If I have the following defined in the top level I would expect When I was working with Nx, we defined the directory where the task was running using Obviously, you can always navigate to the right folder you want from there. Example (Nx): "targets": {
"my-target": {
"executor": "@nx/run-commands",
"options": {
"cwd": "{projectRoot}",
"commands": ["echo 'Running from project root'"]
}
}
}Personally, I would not necessarily introduced something like "invocation_root" as you (usually) want to invoke a specific task from anywhere so that will confuse people I think. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I think the expected behavior for inherited tasks now that we have monorepo path syntax is if the user types //path/to/project:inherited_task, the task runs in //path/to/project If the user wanted inherited_task to run in path/ they could type //path:inherited_task I see what you mean that invocation_root is a confusing name. Should be something indicating "run it at the path asked for with my monorepo syntax." |
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.
-
|
Posted a pr for the mise task deps issue here: #7699 |
Beta Was this translation helpful? Give feedback.
-
|
Fixed in 2026.1.4 |
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.
-
|
Can monorepo work with autocompletion? I can't get this working |
Beta Was this translation helpful? Give feedback.
-
|
+1 @jdx completions are still broken. Can target once all the task resolution bugs are fixed. |
Beta Was this translation helpful? Give feedback.
-
|
do we already have project alias? e.g
|
Beta Was this translation helpful? Give feedback.
-
|
I would love to see this kind of alias. Would need to be an option included in the directory's mise.toml. This is one of two issues that would allow me to completely drop Taskfile for some work projects and do everything in mise. |
Beta Was this translation helpful? Give feedback.
-
|
I hit a bug with cat ./mise.toml cat a/mise.toml Only the last run works as intended, it seems that sources doesn't correctly change directory before As anyone been hit by this and has a workaround? Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Okay I found a workaround: works. |
Beta Was this translation helpful? Give feedback.
-
|
I was trying to run something like this: mise //project-a:ci ::: //project-b:ciwith something like this: # project-a/mise.toml
[tasks.lint]
run = "echo 'project-a lint'"
[tasks.test]
run = "echo 'project-a test'"
[tasks.ci]
depends = [":lint", ":test"]# project-b/mise.toml
[tasks.lint]
run = "echo 'project-b lint'"
[tasks.test]
run = "echo 'project-b test'"
[tasks.ci]
depends = [":lint", ":test"]but getting an error like Reproduction here: https://github.com/chadxz/mise-monorepo-multiple-deps-repro |
Beta Was this translation helpful? Give feedback.
-
|
to be clear what I would ultimately like to be able to do is like this: mise //project-a:ci //project-b:ci -j $(nproc)the project list would be the result of running |
Beta Was this translation helpful? Give feedback.
-
|
Push a PR to fix this: #7698 |
Beta Was this translation helpful? Give feedback.
-
|
Fixed in 2026.1.4 |
Beta Was this translation helpful? Give feedback.
-
|
When running monorepo tasks like Example structure that fails: Workaround: mise -C ./parent/child run //parent/child:task works because it forces mise to load configs from that directory. |
Beta Was this translation helpful? Give feedback.
-
|
pr for this was merged. |
Beta Was this translation helpful? Give feedback.
-
|
Fix for this was released in https://github.com/jdx/mise/releases/tag/v2026.1.2 |
Beta Was this translation helpful? Give feedback.
-
|
Currently (as of From From repo root, the task fails: Verbose output confirms the cause — from root, only root configs are loaded: From the task's directory, the full hierarchy loads: Workaround: Expected: Running a |
Beta Was this translation helpful? Give feedback.
-
|
Fixed in 2026.2.21 in <48h which was instantly available on brew. Amazing! ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
Will there be support for task caching in the future? |
Beta Was this translation helpful? Give feedback.
-
|
Hello, a recent version added tasks heritage, were tasks from mise.toml in other directories than the current one are magically available. There is no |
Beta Was this translation helpful? Give feedback.
-
|
it's not implemented yet but I was thinking something like this: [tasks.build]
extends = "python:build"
vars = {venv = "~/.venv1"}then you could use tera in the template to do something like this: [task_templates."python:build"]
depends = ["VENV={{vars.venv}} setup-venv"] |
Beta Was this translation helpful? Give feedback.
-
|
of course, we could just add that feature to task_config.includes |
Beta Was this translation helpful? Give feedback.
-
|
in terms of overriding, I think the behavior is that if you override it will replace everything and not merge, so you can't do this (with task_config.includes): [tasks.build]
env = {foo = "bar"}templates do support that, but again, we could probably make task_config.includes merge as well |
Beta Was this translation helpful? Give feedback.
-
|
Gothca. TBH I'd personally be nervous about using template expansions like that (with tera. ex: escaping spaces/special chars) and would probably just rely on env vars, so that particular feature isn't something I'll use. I'm mostly concerned with a having a way to get a set of tasks that are common to a project type (ex: "node web service" or "rust binary crate") and re-use them. task_config.includes is doing that well for me so far. And even better now with 2026.1.9 w/o the inheritance! (unrelated) Was just giving a demo of mise to a coworker, and in like 30 seconds we were able to add a |
Beta Was this translation helpful? Give feedback.
-
That's what I was getting at. Why make templates a separate thing? Why not just allow tasks to generally be extendable? (opt-in, of course) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for implementing this! Are there any plans on implementing affected files detection? This is the main missing link that is needed in a monorepo. |
Beta Was this translation helpful? Give feedback.
-
|
@dudicoco Mise already supports this (before monorepo support) via task |
Beta Was this translation helpful? Give feedback.
-
|
@NfNitLoop i'm aware of task source and outputs, that's not the same as affected detection according to git status. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, I think you might also not want "prepare" to be inherited. (or, like tasks, have some explicit way to reuse prepare tasks.) My use case: I'm working in a monorepo that has some base setup steps to get things working after checkout. So in my root config.toml, I've got a prepare task to take care of that. But, now every project seems to have inherited the "prepare" so when I run Additionally, unlike the way inherited tasks worked, the prepare task seems to be using the pwd of the inner projects, not the root, so some of my prepare tasks fail. One of my prepare tasks is running I really like making the tasks have unified namespace so I can run or depend on tasks from everywhere in the repo, but inheritance is having very unexpected behavior. 😅 (I'm using 2026.1.9) |
Beta Was this translation helpful? Give feedback.
-
|
I've just had to remove all prepare tasks from the monorepo root in the meantime. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, I saw what I thought was a fix in #7889 (released in 2026.1.11) So I went to try it out and figured out that I had was misreading output. In my prepare, I had: run = "cd inner_path; do_thing"But unlike task.run, I think that's not getting piped through a shell, so it's trying to run that as a single command, and telling me the path is incorrect. (Which I had taken to mean that it was being run in the wrong path.) So, oops, sorry for the false report there. 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I am preparing to migrate away from automatic discovery as per the deprecation notice. However, maintaining a static list of explicit paths in [monorepo].config_roots is difficult for our workflow, as projects are frequently added or moved. Currently, I work around this by generating the TOML configuration dynamically using git ls-files to locate all mise.toml instances: git ls-files --exclude-standard "*/mise.toml" | sed "s#/mise.toml\$##;s#^\(.*\)\$#'\1',#;1i [monorepo]\nconfig_roots = [" && echo ']'Would it be possible to add a configuration option that allows mise to execute a command to populate config_roots? This would provide the best of both worlds: explicit control over discovery logic (e.g., respecting .gitignore) without the manual maintenance of a hardcoded list. Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
you might consider a git hook for keeping the main list updated |
Beta Was this translation helpful? Give feedback.
-
|
My assumption is that mise removed the auto-discovery because:
So it's better to be explicit. Adding in a feature that essentially does the behavior that was just removed would run into the same issues. But… if you have a sed script that can do this for you,, can't you just make it a mise task? That seems like a good solution. You have (via your script) explicitly set the rules for which directories you want to search and which mise.toml files you want to include. |
Beta Was this translation helpful? Give feedback.
-
|
I understand the rationale regarding performance constraints on large repos and avoiding accidental discovery in submodules or vendored directories. However forcing explicit configuration on everyone adds significant friction for those of us with "freer" file structures. While I do use a mise task (wrapping the sed script) to generate the list, it solves the "how" but not the "when." I still have to remember to run it every time I add a mise.toml. If I forget, the environment is out of sync, which defeats the purpose of using a tool like mise to automate my workflow. Proposed Alternatives: Instead of deprecating auto-discovery entirely, could we consider:
|
Beta Was this translation helpful? Give feedback.
-
|
auto-discovery was a terrible idea, it's not coming back |
Beta Was this translation helpful? Give feedback.
-
|
Could you link a discussion thread as to why it was a terrible idea? What about giving the option to run a user written task to fill up config_roots? |
Beta Was this translation helpful? Give feedback.
-
Remaining task inheritance issuesMost of the task inheritance was removed in 2026.1.9, but I'm still seeing a bit of it. (using v2026.1.11) For example, given: ## --- mise/common.tasks.toml ---
[common-task]
run = "echo common-task ran"
[build]
description = "common build task"
run = "echo common build ran"## --- mise/config.toml ---
experimental_monorepo_root = true
monorepo.config_roots = [ "packages/*" ]
settings.experimental = true
[tasks.root-task]
run = "echo ran root task"
[tasks.build]
description = "monorepo-wide build"
run = "echo ran root build"## --- packages/foo/mise/config.toml ---
task_config.includes = [
"../../../mise/common.tasks.toml"
]
[tasks.foo-task]
run = "echo foo-task ran"Then:
But within one of the single packages, there's odd behavior:
(I do see all tasks with Additionally, running local tasks doesn't work as expected: foo-task works, though: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed report! I've submitted a PR to fix these issues: #7917 Issue 1: Tasks from included files not showing in The problem was that Issue 2: When running Both issues should be resolved once this PR is merged. This reply was generated with AI assistance. |
Beta Was this translation helpful? Give feedback.
-
TBH, resolving from Thanks for the quick fixes! Demoed mise to a wider audience at work today (and thankfully saw these bugs before the demo, so routed around them). Once these fixes land I'll be in a better place to ask that we at least experimentally start using mise. 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
I'm seeing the exact same issue ("mise build fails but suggests the same task"). On v2026.2.13 Global ( [task.hello]
run = "echo hello"Monorepo root ( experimental_monorepo_root = true
[settings]
task.monorepo_depth = 2
task.monorepo_respect_gitignore = false
[monorepo]
config_roots = ["build_*"]Inside the subproject ( Trying |
Beta Was this translation helpful? Give feedback.
-
Prepare steps not executed in sub-directories(aside: Should we report monorepo-related bugs here? Or just make new top-level discussions?) v2026.2.15-16 In a monorepo, I have: # foo/.mise/config.toml
[prepare.npm-ci]
# rerun `npm ci` as needed:
auto = true
sources = [
"package.json",
"package-lock.json",
]
outputs = [
"node_modules",
]
run = "npm ci"When I run But if I IMO it should either run both, or give an error/warning about prepare steps not being valid in inner directories. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I see this was addressed here: #8291 and included in https://github.com/jdx/mise/releases/tag/v2026.2.18. I'll give that a try. |
Beta Was this translation helpful? Give feedback.
-
|
This is still not working for me in .20. I'll try to make a repo w/ a minimal reproduction. |
Beta Was this translation helpful? Give feedback.
-
|
Here's a reproduction: |
Beta Was this translation helpful? Give feedback.
-
|
fixed in https://github.com/jdx/mise/releases/tag/v2026.2.21 🎉 |
Beta Was this translation helpful? Give feedback.
-
|
Is overriding tasks from included files supposed to work? I have a case where I define a task with the same name as from the included file, but Mise still runs the included task. |
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