Hacker News Reader

Comment by spankalee | Hacker News Reader

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/

View on HN

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.

ah I think I misinterpreted this to mean remote caching

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.

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.

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

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.

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.

That's remote caching. Local caching is still very important, and I guess it does support that.

Thanks for the clarification. I don't use any tools that do remote caching so I guess I just glossed over that qualification. :o/

What's a remote task in this context?

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.

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.

Reply on news.ycombinator.com