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

La proposition mentionne la configuration actuelle de just et les workflows du dépôt, mais ne nomme aucun fichier ni test. Commencez par examiner comment les tâches existantes sont organisées et par comparer cela aux capacités de Vite Task pour ce monorepo axé sur Rust. Pour considérer le travail comme terminé, il faudrait définir d’un commun accord le périmètre de la migration et les critères de réussite, ce que l’issue ne précise pas.

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.