Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,848 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@wan9chi đang làm issue này rồi.

Từ ngày 2/10/2026.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
cli, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Rust
Star
6k
Fork
271
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
198

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của voidzero-dev/vite-plus

Tất cả issue của voidzero-dev/vite-plus

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.