RFC：Add minimum-release-age for Vite+ version selection
メンテナーはふだん 1 日以内に返信
@naokihaba がすでに取り組んでいます。
2026年9月14日 から。
評価
この issue はまだ評価されていません。
説明
Context
Setting version to latest lets you pick up new Vite+ releases without manually bumping versions. It's also what setup-vp falls back to when it can't resolve a version from the project.
Current version resolution process
The downside is that CI can pick up releases immediately after publication. To mitigate supply chain risks, it'd be useful to have a waiting period before adopting brand-new versions. Pinning versions works, of course, but a delay lets people keep auto-updating while allowing time for problems or compromised releases to be discovered. This doesn't guarantee security. mise-action already supports something similar with its minimum_release_age option.
This applies only to the Vite+ CLI itself, not project dependencies.
Proposal
Add an optional minimum-release-age input.
- uses: voidzero-dev/setup-vp@v1
with:
version: latest
minimum-release-age: 3
The input would take a non-negative integer representing days (24-hour periods). Setting it to 3 means a release must be at least 72 hours old.
Expected behavior:
- When resolving
latest(or falling back to it), pick the highest stable version that meets the age requirement. - Leave pinned versions and versions resolved from lockfiles unchanged.
- Omitting the input or setting it to
0keeps the current behavior. - Reject invalid values, such as negative numbers or non-integers, with a clear error.
- When an age requirement is enabled, fail with a clear error if no release qualifies or publication metadata cannot be retrieved, rather than silently bypassing the requirement.
- Log the chosen version along with its publication timestamp.
One tradeoff is that CI may select an older version than a local environment using the current latest. Explicitly setting version: latest also takes precedence over project version detection. Users who need matching versions should pin Vite+ in their project and let setup-vp resolve that version.
I think scoping this to latest makes sense for now. Ranges and prerelease tags can be considered separately. Ideally, the selection logic would be shared across the GitHub, GitLab, and Azure entry points.
This might be more defensive than necessary for setup-vp, so I'd appreciate your candid thoughts on whether it belongs here.
- 主要言語
- TypeScript
- スター
- 111
- フォーク
- 22
- 平均マージ
- 1日 1時間
- マージ済み PR（30日）
- 28
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
voidzero-dev/setup-vp のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
voidzero-dev/setup-vp#164 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Restore SFW blocking tests after Socket API errors are fixed対応中かも @fengmk2 が 16 日前に担当しました。 オープン
voidzero-dev/setup-vp#161 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
Track: enable `sfw` on macOS/Windows once vp + sfw upstream TLS issues are resolved再び着手できるかも @fengmk2 が 129 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンenhancement
voidzero-dev/setup-vp#73 · リアクション 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
Support sh fallback for install script on Alpine再び着手できるかも @fengmk2 が 192 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
voidzero-dev/setup-vp#32 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
voidzero-dev/setup-vp の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
aiko-chan-ai/DiscordBotClient#380 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
vercel/ai-elements#507 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 半日 初心者へのやさしさ 84/100
anaclumos/qa-interns#148 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信