no flags, no parallel tasks, no skipping tasks unless files change, no watching for changes
come see a modern task manager: https://mise.jdx.dev/tasks/
1,380 karma · joined March 19, 2020
come see a modern task manager: https://mise.jdx.dev/tasks/
I think this is all fine though. I'm hard at work improving mise and will continue to do so for the foreseeable future. If someone is hesitant, I'd rather they wait a year until more kinks have been worked out, docs have been improved, feature gaps are closed, etc. I think this is especially true for tasks which only came out of experimental a few weeks ago.
Or people can just not use it. It's not like this is a business where I make more money when I have more DAU or anything. I just want to build a good tool for building sake after all.
file tasks are basically just a directory of bash (or whatever shebang) scripts, but special comments give them extra functionality like dependencies or defining flags/options.
The biggest advantage just has is that it's been around longer, in mise tasks only came out of experimental like a month ago. mise tasks themselves are stable, but there are still experimental things and some portions that need to be used more—like windows. That said, most of the stuff that needs polish are features just doesn't even have.
I had a look at the top issues for just and pretty much all of them I've handled in mise: https://github.com/casey/just/issues?q=is%3Aissue+is%3Aopen+...
here's my unashamedly biased thoughts on why I like mise tasks compared to just:
* tool integration - this is the obvious benefit. If you run `mise run test` on CI or wherever it'll setup your toolchains and wire them up automatically
* parallel tasks - I saw this as table-stakes so it's been there since the very beginning
* flags+options - mise tasks are integrated with usage (https://usage.jdx.dev) which provides _very_ comprehensive CLI argument support. We're talking way more than things like flags and default options, as an example, you can even have mise tasks give you custom completion support so you can complete `mise run server --app=<tab><tab>`
* toml syntax - it's more verbose, but I think it's more obvious and easier to learn
* file sources/outputs - I suspect just doesn't want to implement this because it would make it more of a "build tool" and less of a "task runner". I chose to despite having the same position that mise tasks is also not a "build tool". Still, I think even in the world of running tasks you want to only run things if certain files changed often.
* `mise watch` - this is mostly just a simple wrapper around `watchexec -- mise run ...` for now, but it's an area of the codebase I plan to focus on sometime in the next few months. Still, even as a simple wrapper it's a nice convenience.
* "file tasks" - in mise you can define tasks just by being executable and in a directory like "./tasks". This is great for complex scripts since you don't also need to add them to mise.toml.
I have not used just very much, but I did go through the docs and there are a handful of things I like that it definitely does better:
* help customization - it looks like you can split tasks into separate sections which is nice, I don't have that
* invoking multiple recipes - I don't love how this is done in mise with `mise run task1 ::: task2` but I _also_ wanted to make it easy to pass arguments. At least for now, the ":::" won out in the design—but I don't like it. Probably too late to change it anyhow.
* [no-cd] flag - both just and mise run tasks in the directory they're defined, but I prefer how this is overridden in just vs mise.
* expression/substitutions - mise uses tera for templating, which is very flexible, but it requires a bit more verbosity. I like that in just you can just use backticks or reference vars with minimal syntax. Same thing with things like joining paths and coalescing. I have all of this, but the syntax is definitely more verbose in mise. Arguably though, mise's verbosity might be easier to read since it's more obvious what you're saying.
* confirmation - I love that in just you can just add `[confirm]` to get a confirmation dialog for the task. I'm sure we'll get around to this at some point, mise already has confirmation dialogs so it shouldn't be hard to add. The tricky part will be getting it to work right when running a bunch of stuff in parallel.
* task output - I haven't used just that much so I can't actually say that it's "better", but having more control over how tasks are output is definitely a weak part of mise right now and is in need of more functionality like in just how you can add/remove "@" to echo out the command that's running
I want to call out one very silly thing that from reading these github issues sounds crazy. It sounds like both just and taskfile have the same behavior with `.env` files. In just and taskfile, variables defined in .env are ignored if they're already defined. I don't think anyone would want that—nobody has asked for mise to behave that way—and it doesn't appear either tool even allows you to change it!
In the future though I see tasks as being the headline for mise over tools. That's a ways out, certainly more than a year, but the thing about tasks is they don't suffer from the drawbacks that both PATH and shims have for putting your tools in the right place. In my personal use of mise I don't actually like using `mise activate` whatsoever. The problem is just that I can't yet do everything with tasks easily enough. Tasks need to get to a point where they're so easy you won't want to bother with having tools in your shell.
Though who knows. I may be off my rocker on that one. I certainly get things wrong as much, if not more, than I get them right.
That said, I think if you thought about _why_ you like minimalistic and predictable tools you may find that mise solves the underlying reasons for that. My whole thing is about augmenting your environment and not replacing it. This is generally where I contrast mise with tools like nix and docker but I thought it was worth calling out.
I think people like mise because they can use it for just setting some env vars, installing a few npm packages globally, having an easy way to synchronize tool versions between local dev and CI/CD. You can use it for any one of those things and it slots right in wherever you are—whether that's inside VSCode, ssh'ed into a remote machine, in a github action, or inside a docker container in a k8s fleet.
Yeah mise is capable of a lot of different things, but the important thing is that it doesn't force you to change anything _else_ about your setup.
It'll be a long road ahead and I could certainly use some help if anyone out there is interested in moving it forward. That said, vfox is a really great project and they are targeting windows specifically. Windows will probably always be second in the mise ecosystem (because I don't use it) but my hope is I can get at least a baseline of support which would help teams that have occasional windows contributors.
this is a use-case I should be more thoughtful around. I do try to never ever block on HTTP for anything where you aren't explicitly calling mise—so like `mise ls-remote` obviously is going to block, but if mise is just running to update PATH behind the scenes it should never, ever cause any significant delay. If you ever see this happen try to let me know—though I understand that by its nature that can be a very difficult thing to reproduce.
> conceptually becomes a distribution package manager
I talk about this a lot in private but I don't think it's in any docs but this is expressly not something I would ever do. Mise stops at your system. I'll never try to install openssl or something to patch your system or get libraries in place. Nix is the tool for people that want that sort of thing.
IMO the biggest competitor to mise isn't asdf, it's nix and docker and mise is the polar opposite of both. That's not to say those tools don't have their place but at their core: docker and nix try to _bypass_ your environment by building their own. Mise augments your environment which means you don't need to figure out how to get stuff into or out of the environment. You environment is what it was before, just with tools, env vars, and tasks to make working in that environment easier.
However yes, this does mean you may be missing a shared object from time to time. Or need to install libxml. But at least you don't need to setup rsync.
The reason people like mise is hard to put in a post because its really the care and countless hours I've put into working through workflow after workflow over and over. Testing things out. Going back on decisions I felt like weren't as good as they could've been. Reading and re-reading code in both my own codebase and asdf's. My niche is building CLIs and I am grateful to be able to work on something people are finding so much value in. Understand mise didn't start last year, I've been planning this project for over a decade while working on other CLIs and dev tools.
Here's an example of one: in mise the shims will fall back to system versions. So if you have a shim for `ruby` but you only use ruby in 1 project without a global set then calling ~/.local/share/mise/shims/ruby will go to the next thing on PATH, so maybe /opt/homebrew/bin/ruby. In asdf, the shim will fail outright unless you explicitly set "system" as the version in your global config.
At the end of the day though, I know not everyone will like mise. I certainly have a particular style of building tools and managing the project that works for some and doesn't for others. Ultimately I think this allows me to build tools that while they may never be universally adopted will be more enjoyed by those that it rings true for. Of course if you don't like it I'd be particularly interested to hear what is is you don't enjoy.
It is funny to me something can so well liked while also causing a lot of problems. Maybe not too dissimilar from the whole rtx -> mise debacle :p
I don't know about you but "performance upgrades on ancient hardware" isn't exactly the sort of thing my manager would be terribly happy I was focusing my time on.
At that point it would make sense for them to also make scaffolding generators, meaning the cli author only has to write one spec and don’t have to repeat the effort for their code so much.
It gets way too complicated real quick and a lot of things you _dont_ want to expose in documentation. It’s better to generate docs from a spec than the other way around, I’m pretty sure of this now.
I am working on it here: https://github.com/jdx/usage
It's mostly just a README right now, and I'm still iterating on it, talking to friends, but I think I'm getting close. It's definitely not yet written for the average developer to consume yet either. My hope is within the next month or two I might have a usable alpha release of it. I have a use-case for it now so I think it’s finally ready to happen.
If you have any thoughts on my design lmk.
I'm American, but I have enough friends and family from other countries (my wife is an Iranian passport holder) to know what you're talking about and how difficult it can be.
EDIT: just tested on the eslint codebase:
cold (nothing installed, no cache): bun: 1.53s, pnpm: 8.25s, npm: 25s
hot (already installed, noop): bun: 218ms, pnpm: 1300ms, npm: 1230ms
I've swapped much of my usage of npm over to bun. I still work on projects where nobody else is using bun, but I can run `bun install` instead of `npm install` and `bun run` instead of `npm run` and these run probably 100x faster.