Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#2,848 0 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@wan9chi arbeitet bereits daran.

Seit 02.10.2026.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
cli, tooling

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
Rust
Sterne
6.5k
Forks
296
Ø Merge
1 T. 12 Std.
Gemergte PRs (30 T.)
229

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus voidzero-dev/vite-plus

Alle Issues in voidzero-dev/vite-plus

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

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