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

Der Vorschlag erwähnt das aktuelle just-Setup und die Workflows des Repositorys, nennt aber keine Dateien oder Tests. Beginne damit, zu prüfen, wie die vorhandenen Tasks organisiert sind, und dies mit den Fähigkeiten von Vite Task für dieses auf Rust ausgerichtete Monorepo zu vergleichen. Als abgeschlossen könnte die Arbeit erst gelten, wenn ein abgestimmter Migrationsumfang und Erfolgskriterien festgelegt sind, die der Issue nicht definiert.

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.