Proposal: Dogfood Vite Task in this repository (self-host the repo tasks)
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 25/100
- Issue 類型
- 功能
- 描述清晰度
- 需要釐清
- 活躍度
- 停滯
- 技術堆疊
- rust, vite
- 領域
- build-system, tooling
研究方向
此提案提到了目前的 just 設定和 repository workflows，但沒有列出任何檔案或測試。先檢視現有 tasks 的組織方式，並將其與 Vite Task 對這個以 Rust 為主的 monorepo 所具備的功能進行比較。若要視為完成，必須先就 migration 範圍和成功標準達成共識，而該 issue 並未定義這些內容。
由索引模型根據 Issue 內容生成。
描述
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.
- 主要語言
- Rust
- 星號
- 468
- 分支
- 42
- 平均合併
- 1 天 18 小時
- 30 天內合併 PR
- 46
環境準備
在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
voidzero-dev/vite-task 的其他 Issue
-
vp run: output forwarding fails with EAGAIN when an inherited Node child sets stdout non-blocking未關閉
難度 4/5 3-5 天 新手友好度 48/100
voidzero-dev/vite-task#782 · 1 則留言 ·
維護者通常 1 天內回覆
-
remote cache
難度 5/5 一週以上 新手友好度 35/100
voidzero-dev/vite-task#781 ·
維護者通常 1 天內回覆
-
remote cache
難度 4/5 3-5 天 新手友好度 55/100
voidzero-dev/vite-task#779 ·
維護者通常 1 天內回覆
-
remote cache
難度 5/5 一週以上 新手友好度 35/100
voidzero-dev/vite-task#778 ·
維護者通常 1 天內回覆
-
fspy misses Bun file reads on Linux (glibc), so cached tasks replay stale output可能已有人在做 @wan9chi 於 2 天前認領。 未關閉fspy
voidzero-dev/vite-task#777 · 1 則留言 · 已指派 1 人 ·
維護者通常 1 天內回覆
查看 voidzero-dev/vite-task 的全部 Issue
相似的 Issue
-
ai_p2
難度 2/5 1-3 小時 新手友好度 76/100
ClickHouse/ClickHouse#123351 ·
維護者通常 1 天內回覆
-
documentation
難度 1/5 1 小時以內 新手友好度 92/100
github/copilot-sdk#2804 · 1 則留言 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 86/100
lance-format/lance#9655 ·
維護者通常 2 天內回覆
-
bug language::rust router
難度 2/5 1-3 小時 新手友好度 84/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
Vector35/binaryninja-api#8621 · 1 則留言 ·
維護者通常 2 天內回覆