feat: mark task-spawned processes with VP_RUN - #570
Merged
Conversation
wan9chi
force-pushed
the
feat/task-marker-env
branch
from
July 26, 2026 13:23
265c6d2 to
6d20c17
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 265c6d25da
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
## Motivation A tool started from a task cannot tell whether it was launched by `vp run` or typed directly. Vite+ needs that distinction: its built-in commands point at `vpr <name>` when a same-named script exists, which is misleading when that very script is what spawned them. Every spawned task now carries `VP_RUN=1`. It is set after `env`/`untrackedEnv` filtering so a task's passthrough config cannot drop it, and it is forced rather than inherited so a stale parent value cannot make a task look like a direct invocation. A prefix assignment on the command still wins. The name is exported as `MARKER_ENV_NAME` so consumers do not hardcode it. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
wan9chi
force-pushed
the
feat/task-marker-env
branch
from
July 26, 2026 13:31
6d20c17 to
e54f421
Compare
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 26, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no such script, and when the task runner
spawned the command, since the user is then already on the `vpr` path. That
second case relies on `VP_RUN`, added in voidzero-dev/vite-task#570, which is
why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 27, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 30, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 30, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 30, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 30, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 30, 2026
Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server
even in a project whose `dev` script does something else entirely. Users
regularly reach for the built-in when they meant the script.
Every built-in that can be mistaken for a script now prints:
note: You are running `vp dev` as a Vite+ built-in command. If you meant
to run the dev npm script, use `vpr dev` instead.
It stays quiet when the project has no script of that name, when stdout is not
a terminal (IDEs read it as formatted source or the LSP protocol), and when the
task runner spawned the command, since the user is then already on the `vpr`
path. That last case relies on `VP_RUN`, added in voidzero-dev/vite-task#570,
which is why the vite-task revision moves with this change.
Refs #2243
graphite-app Bot
pushed a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 30, 2026
…ipt (#2259) ## Motivation Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server even in a project whose `dev` script does something else entirely (a framework wrapper, extra flags, a custom runner). Users regularly reach for the built-in when they meant the script — see #2243. Stacked on #2265 (notes go to stderr) and #2262 (the raw subcommand reaches this CLI). ## What this does When the user writes `vp <name>` and `<name>` is both a built-in and a `package.json` script: ``` note: You are running `vp dev` as a Vite+ built-in command. If you meant to run the dev npm script, use `vpr dev` instead. ``` The trigger is the name as written. It comes from `VP_RAW_SUBCOMMAND` when the global CLI provides it, since that is the only accurate source once a command has been resolved to its canonical name — `vp format` names the `format` script, not `fmt`. Otherwise it comes from the command line, where a rewrite is rejected: `vp help fmt` runs as `fmt --help`, and writing `help` is not writing the built-in. The only suppression is `VP_RUN`, set by the task runner (voidzero-dev/vite-task#570), since the user is then already on the `vpr` path. There is no TTY check: the note goes to stderr, so an agent capturing piped output still sees it while parsed stdout — `oxlint -f json`, `vitest --reporter=json`, `oxfmt --stdin-filepath` — stays intact. Script lookup walks up to the nearest `package.json`, the package `vp run` itself resolves a task from, so the note also applies from a subdirectory and deliberately stops there rather than climbing to a package `vpr` could not reach. Only the built-ins are covered. `run`/`cache` are the script path itself, `install` and friends legitimately trigger a project's `install` lifecycle scripts through the package manager, and `exec` names a binary rather than a task. `vp_build_cache` and `vp_build_cache_monorepo` are re-recorded: both define `"build": "vp build"` and run `vp build` directly, so they now show the note. Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 30, 2026
…ipt (#2259) ## Motivation Built-in commands cannot be overridden, so `vp dev` runs the Vite+ dev server even in a project whose `dev` script does something else entirely (a framework wrapper, extra flags, a custom runner). Users regularly reach for the built-in when they meant the script — see #2243. Stacked on #2265 (notes go to stderr) and #2262 (the raw subcommand reaches this CLI). ## What this does When the user writes `vp <name>` and `<name>` is both a built-in and a `package.json` script: ``` note: You are running `vp dev` as a Vite+ built-in command. If you meant to run the dev npm script, use `vpr dev` instead. ``` The trigger is the name as written. It comes from `VP_RAW_SUBCOMMAND` when the global CLI provides it, since that is the only accurate source once a command has been resolved to its canonical name — `vp format` names the `format` script, not `fmt`. Otherwise it comes from the command line, where a rewrite is rejected: `vp help fmt` runs as `fmt --help`, and writing `help` is not writing the built-in. The only suppression is `VP_RUN`, set by the task runner (voidzero-dev/vite-task#570), since the user is then already on the `vpr` path. There is no TTY check: the note goes to stderr, so an agent capturing piped output still sees it while parsed stdout — `oxlint -f json`, `vitest --reporter=json`, `oxfmt --stdin-filepath` — stays intact. Script lookup walks up to the nearest `package.json`, the package `vp run` itself resolves a task from, so the note also applies from a subdirectory and deliberately stops there rather than climbing to a package `vpr` could not reach. Only the built-ins are covered. `run`/`cache` are the script path itself, `install` and friends legitimately trigger a project's `install` lifecycle scripts through the package manager, and `exec` names a binary rather than a task. `vp_build_cache` and `vp_build_cache_monorepo` are re-recorded: both define `"build": "vp build"` and run `vp build` directly, so they now show the note. Refs #2243
wan9chi
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
Jul 31, 2026
Release vite-plus v0.2.7: Clearer commands and smoother setup. This release makes built-in and package-script collisions easier to navigate, adds concurrency control to `vp pack`, and smooths migrations and package-manager setup. ### Highlights - Guide users to `vpr <name>` when a built-in shares a name with a `package.json` script, preserve the exact command alias they typed, and avoid duplicate notes from task-spawned tools ([#2262](#2262), [#2259](#2259), [vite-task#570](voidzero-dev/vite-task#570)), by @wan9chi - Add `--concurrency` to `vp pack` to limit parallel Rolldown builds, and update tsdown `0.22.13` -> `0.22.14` and Vite DevTools `0.4.2` -> `0.4.5` ([#2233](#2233)), by @voidzero-guard[bot] - Add read-only Svelte rune globals to migrated Oxlint overrides, preventing false `no-undef` errors ([#2192](#2192)), by @naokihaba - Install package managers from npm tarballs with nonstandard top-level directories, fixing Yarn 1.22.19 installation ([#2264](#2264)), by @TheAlexLichter ### Fixes & Enhancements - Preserve machine-readable command output by sending informational CLI notes to stderr ([#2265](#2265)), by @wan9chi - Prevent the Oxc language server from crashing when contributors open the Vite+ workspace in VS Code ([#2245](#2245)), by @jong-kyung ### Docs - Document the full procedure for removing Vite+ commit hooks ([#2218](#2218)), by @TheAlexLichter - Document per-process and per-machine ways to disable Vite+ commit hooks without uninstalling them ([#2230](#2230)), by @TheAlexLichter - Clarify when to use built-in `vp` commands versus package scripts through `vp run` or `vpr`, including migration and agent guidance ([#2255](#2255)), by @wan9chi - Document GitLab CI/CD setup with the reusable `setup-vp` template ([#2258](#2258)), by @naokihaba ### Chore - Run Semgrep security scans on pull requests and pushes to `main` ([#2223](#2223)), by @Boshen - Re-enable Vitest browser-mode CLI snapshot coverage on every supported platform ([#2275](#2275)), by @wan9chi - Stabilize Windows CLI snapshot tests for interrupted installs and browser port fallback ([#2282](#2282)), by @wan9chi - Replace deprecated shared JavaScript and TypeScript VS Code settings with their current `js/ts.*` names ([#2246](#2246)), by @jong-kyung ### Bundled Versions | Tool | Version | Source | | --------------- | ---------- | ----------------------------------------------------------------------- | | vite | `8.1.5` | [`5e7fe12`](vitejs/vite@5e7fe12) | | rolldown | `1.2.0` | [`03e1e34`](rolldown/rolldown@03e1e34) | | tsdown | `0.22.14` | [npm](https://npmx.dev/package/tsdown/v/0.22.14) | | vitest | `4.1.10` | [npm](https://npmx.dev/package/vitest/v/4.1.10) | | oxlint | `1.75.0` | [npm](https://npmx.dev/package/oxlint/v/1.75.0) | | oxlint-tsgolint | `7.0.2001` | [npm](https://npmx.dev/package/oxlint-tsgolint/v/7.0.2001) | | oxfmt | `0.60.0` | [npm](https://npmx.dev/package/oxfmt/v/0.60.0) | ### Upgrade ```bash vp upgrade ``` **Full Changelog**: v0.2.6...v0.2.7 --- Merging this PR will trigger the release workflow. --------- Co-authored-by: voidzero-guard[bot] <278573678+voidzero-guard[bot]@users.noreply.github.com> Co-authored-by: wan9chi <dk4rest@gmail.com>
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
A tool started from a task cannot tell whether it was launched by
vp runortyped directly. Vite+ needs that distinction: its built-in commands point at
vpr <name>when a same-named script exists, which is misleading when thatvery script is what spawned them.
Every spawned task now carries
VP_RUN=1. It is set afterenv/untrackedEnvfiltering so a task's passthrough config cannot drop it, and it is forced
rather than inherited so a stale parent value cannot make a task look like a
direct invocation. A prefix assignment on the command still wins. The name is
exported as
MARKER_ENV_NAMEso consumers do not hardcode it.Co-authored-by: Claude Opus 5 noreply@anthropic.com