Proposal: task metadata (description) + aliases/groups for discoverability at scale

[ubugeeei]

Problem

As task count grows, discoverability becomes a major UX issue.
just provides aliases and groups; it also has strong listing/help UX. Vite Tasks appears command-centric and does not expose first-class description/alias/group metadata in the task schema (based on the public schema file).

Evidence (primary)

• Task schema appears centered around command without rich metadata fields.

Ref:

• https://github.com/voidzero-dev/vite-task/blob/main/crates/vite_task_graph/run-config.ts

Proposed behavior (Unspecified)

• Add optional fields:
  • description?: string
  • aliases?: string[]
  • group?: string
• Display description/group in task listing and error messages.
• Allow running a task via any alias, with clear conflict handling (unspecified).

Use cases

• Provide “human intent” descriptions for tasks (deploy, release, verify, etc.)
• Create short entry points via aliases
• Organize tasks into groups (lint/test/build/release) for large monorepos

Backward compatibility

• Purely additive; tasks without metadata behave exactly the same.

Minimal implementation suggestion (MVP)

• Implement description first and show it in listings/output.
• Add aliases resolution later, then group sorting/printing.

Prior art

• just aliases: https://just.systems/man/en/aliases.html
• just groups: https://just.systems/man/en/groups.html

[branchseer]

Some thoughts on each:

aliases: Not necessary as a dedicated field. You can define an alias task that just runs the original: "alias": "vp run task". vite-task statically analyzes and expands nested vp run calls, so there's no process spawning overhead.

description: Useful for the interactive selection list. I'm thinking this could come from JSDoc comments above the task definition rather than a separate field, to keep the schema lean and make it easier to write (no string escapes).

group: Less useful for now. We want task output to be minimal without distraction. Naming conventions like build:web/build:app already serve this purpose. Grouping might become more relevant when we have a UI.