voidzero-dev / voidzero-dev/vite-task

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

Open
#274 1 comment 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
466
Forks
42
Avg merge
1d 15h
Merged PRs (30d)
19

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the vp run documentation, the plan's extra_args pass-through behavior, and the task config schema. First resolve the unspecified argument syntax, validation, help, and -- semantics; done requires an agreed design that preserves unconfigured pass-through behavior and defines the opt-in task experience.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.