Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

`vp run --plan`: print what a run would do, without running it

Aperta
  • Qualcosa non va?
#2,848 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
cli, tooling

Direzione di ricerca

Start at the vp run CLI entry point and trace the existing selection, dependency resolution, compound splitting, ordering, and cache-status handling. Done means --plan performs the usual resolution, prints the requested text or JSON plan, exits without executing tasks, and writes no cache.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Summary

vp run resolves a lot before it executes anything: which packages the selection
picks, each package's task, the commands after compound splitting, the dependsOn
edges and their order, and whether a task would replay from cache. None of it can be
asked for. A --plan flag would print that resolution and exit, in text or JSON, the
way pip install --dry-run --report -, make -n, turbo run --dry=json and
bazel aquery do for their runs.

Motivation

Anything built around a task runner eventually needs to know what a run would do:

  • a pre-tool hook for coding agents that decides whether a shell command is about to
    start something expensive (a type checker, a browser suite) before letting it run;
  • CI that picks jobs from the task graph instead of from path globs;
  • a repository doctor or lint rule that checks task wiring ("does this dependsOn
    reach the task it means to?", "which packages drop out of -r for this task?");
  • a person or an agent asking "what does vp run -r test actually run, in what order?"

Today the only route is to load every vite.config.* yourself and re-implement the
selection rules, the dependsOn forms (task, pkg#task, { task, from }), compound
splitting and ordering, then keep that copy in step with Vite+. The existing surfaces
do not cover it: -v and --last-details describe a run after it ran, the interactive
selector is for a person choosing one task, and loadConfigFromFile resolves one
config with no selection, no edges and no cache status.

Prior art

  • pip install --dry-run --report -: resolve, print the JSON report, install nothing.
  • make -n / --dry-run: print the commands that would run.
  • just --dry-run, gradle --dry-run: list the recipes / tasks that would execute.
  • turbo run <task> --dry / --dry=json: per task, taskId, package, command,
    hash, inputs, outputs, dependencies, dependents, cache status.
  • bazel aquery: the actions (commands) a build would execute.
  • nx run-many -t <task> --graph=stdout: the task graph the command would execute.

Proposal

vp run --plan [--json] <the usual selection: -r | -t | -w | --filter … | [pkg#]task> [--ignore-depends-on]

Same resolution as a real run, then print and exit 0; execute nothing, write no cache.

Text output: one line per task in execution order, package task: command, with
← dep markers for edges. JSON output:

{
  "selection": { "packages": ["@acme/app", "@acme/core"], "task": "build" },
  "tasks": [
    {
      "id": "@acme/core#build",
      "package": "@acme/core",
      "task": "build",
      "commands": ["tsdown", "node scripts/emit-types.mjs"],
      "dependsOn": [],
      "cache": "replay"
    },
    {
      "id": "@acme/app#build",
      "package": "@acme/app",
      "task": "build",
      "commands": ["vp build"],
      "dependsOn": [{ "id": "@acme/core#build", "kind": "topological" }],
      "cache": "execute"
    }
  ]
}
  • commands are the sub-tasks after compound splitting (&& or array form), since
    those are what Vite Task runs and caches.
  • dependsOn entries carry kind: explicit (a dependsOn entry) or topological
    (package-graph order), because the two are what a wiring check needs to tell apart.
  • cache is replay, execute or disabled when the plan already knows it; if input
    hashing is too costly to do just to answer --plan, unknown is fine and an opt-in
    --plan=hash can come later.

Non-goals: not a visualisation (#1182 asks for that; --plan --json is an input it
could consume), and not a change to --last-details.

How we hit it

In a 128-package workspace we wrote an agent hook that needed one bit: does this
vp run … start a TypeScript compiler? Answering it faithfully meant loading all 128
configs (about 1.8 s per call) and carrying ~500 lines that re-implemented selection
and dependsOn. We replaced that with a hard-coded list of task names, which is exactly
what --plan would retire; a lint rule in the same repo reads run.tasks out of the
config AST for the same reason. Happy to test a preview against that workspace.

Related

  • #1182 (dependency graph visualisation) and #1167 (consolidated recursive output)
    need the same resolved list; --plan is its static, machine-readable form.
  • #1231 (hint when config load exceeds 500 ms) is the same gap from the timing side.
  • voidzero-dev/vite-task#738 (dependsOn object form cannot reach a task behind a
    package that lacks it) is the kind of wiring fact a plan with labelled edges shows
    directly.
Lingua principale
Rust
Stelle
5.8k
Fork
267
Merge medio
21h 2m
PR unite (30g)
149

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di voidzero-dev/vite-plus

Tutte le issue di voidzero-dev/vite-plus

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.