Proposal: Dogfood Vite Task in this repository (self-host the repo tasks)

La proposta menziona la configurazione attuale di just e i workflow del repository, ma non indica file o test. Inizia esaminando come sono organizzati i task esistenti e confrontandoli con le funzionalità di Vite Task per questo monorepo incentrato su Rust. Per considerare il lavoro completato sarebbe necessario concordare l'ambito della migrazione e i criteri di successo, che l'issue non definisce.

First of all, sorry if this is a noisy or unnecessary suggestion.

I just wanted to share this with a lot of respect: Vite Task already feels extremely well designed, and I genuinely think it has the potential to be useful beyond the JS/TS ecosystem, including repositories with a strong Rust focus like this one.

At the moment, this repository appears to use just for task orchestration. Since Vite Task itself is a monorepo task runner, I was wondering whether it might be interesting to dogfood it here and gradually self-host the repository tasks with Vite Task itself.

I think this could have a few benefits:

• It would serve as a strong real-world example of Vite Task managing its own development workflows.
• It would demonstrate that the tool is not limited to JS/TS-heavy repositories, but can also fit mixed or Rust-centric monorepos.
• Dogfooding could help uncover UX gaps, missing features, or rough edges earlier.
• It would make the project story even stronger: the tool is good enough to run itself.

I am not suggesting this as “Just is wrong” or that migration should be rushed. just is great, and there may be perfectly good reasons to keep the current setup. I only wanted to suggest that self-hosting could be a compelling direction if it aligns with the project goals.

Even a partial migration could be interesting at first, for example:

• introducing Vite Task for a subset of repository workflows,
• comparing ergonomics/performance with the current setup,
• and expanding only if it proves valuable.

In any case, thank you for building this. It already looks like a really promising piece of tooling, and I would love to see it adopted across ecosystem boundaries, not only in JS/TS projects but also in repositories that include Rust and other languages.