voidzero-dev / voidzero-dev/vite-task

Proposal: first-class task arguments (schema/validation/help) + argument-based branching

Offen
#274 1 Kommentar 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Vorherrschende Sprache
Rust
Sterne
466
Forks
42
Ø Merge
1 T. 15 Std.
Gemergte PRs (30 T.)
19

Beschreibung

Problem

vp run supports passing extra args after the task name (they are forwarded to the task command), but Vite Tasks does not appear to provide a first-class mechanism to:

  • declare an argument schema (types/choices/default/help/env),
  • validate arguments,
  • generate --help for a task,
  • and/or expose argument values to the task definition in a structured way so tasks can branch predictably.

This makes common patterns (deploy targets, feature flags, region selection, dry-run, etc.) rely on ad-hoc shell parsing and reduces discoverability.

Evidence (primary)

  • Vite+ docs: extra args after the task name are passed to the task command.
    (see vp run docs)
  • Plan implementation: extra_args are appended only to the last &&-split command (pass-through model), not parsed/typed.
  • Task config schema appears command-centric and doesn’t show an args/usage-like field.

Use cases

  • deploy <env> where env is one of dev|staging|prod (typed choices)
  • --region, --dry-run, --verbose with defaults and validation
  • Better UX: vp run deploy --help to show a task-specific help screen
  • Avoid duplicating many similar tasks just to vary a parameter

Proposed behavior (Unspecified syntax; proposal is conceptual)

Allow task definitions to optionally declare an argument schema, e.g. (example only):

  • positional args with enum choices
  • flags and options with types, defaults, help text, and env fallbacks

Then, at runtime:

  • validate inputs before execution
  • expose parsed values to the task as env vars (MVP) or templating variables (future)
  • generate task-level help (vp run <task> --help), without breaking existing pass-through

Backward compatibility

  • If a task has no arg schema, behavior remains exactly the same (current pass-through).
  • If a schema exists, only then enable validation/help/env injection.
  • Preserve -- semantics (Unspecified; needs design) to avoid collisions between runner flags and task flags.

Minimal implementation suggestion (MVP)

  1. Add optional args/usage metadata to the task schema (no runtime behavior yet).
  2. Parse task args for tasks that opt in; inject values into env as VP_ARG_<name> (or similar).
  3. Implement --help generation from the schema for opt-in tasks.
  4. Later: allow templating/branching semantics based on parsed args.

Prior art

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne mit der Dokumentation zu vp run, dem Pass-through-Verhalten von extra_args im Plan und dem Task-Konfigurationsschema. Kläre zunächst die nicht spezifizierte Argument-Syntax, Validierung, Hilfe und ---Semantik; abgeschlossen ist die Aufgabe, wenn ein abgestimmtes Design vorliegt, das das nicht konfigurierte Pass-through-Verhalten beibehält und die Opt-in-Task-Erfahrung definiert.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
rust
Bereich
cli, tooling
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Ruhig
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
30/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.