voidzero-dev / voidzero-dev/vite-task
Cached compound command can replay a later step after preceding vp exec rewrites its input
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 466
- Forks
- 42
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 19
Description
Summary
A cached compound command can replay a later && step even after an earlier vp exec ... step rewrites the file that the later step reads.
This is not specific to vp fmt: the same behavior reproduces when the later step is a plain node command that reads and rewrites the generated file.
Repro repo: https://github.com/SegaraRai/vitetask-repro04
Environment
Observed with:
vite-plus:0.1.19- package manager:
pnpm@10.33.2 - Node: 24.x
- OS: Windows
The repro commands below use PowerShell syntax for setting environment variables.
Reproduction
Clone and install:
git clone https://github.com/SegaraRai/vitetask-repro04.git
cd vitetask-repro04
vp install
The repo defines these tasks in vite.config.ts:
tasks: {
generate: {
command: "vp exec node ./scripts/generate.mjs && vp fmt src/generated",
cache: true,
input: ["scripts/generate.mjs"],
},
"generate:normalize": {
command: "vp exec node ./scripts/generate.mjs && node ./scripts/normalize.mjs",
cache: true,
input: ["scripts/generate.mjs", "scripts/normalize.mjs"],
},
}
Case 1, with vp fmt as the second step:
vp cache clean
$env:REPRO_MESSAGE = "first"; vp run generate
$env:REPRO_MESSAGE = "second"; vp run generate
vp fmt src/generated --check
Case 2, with plain node as the second step:
vp cache clean
$env:REPRO_MESSAGE = "first"; vp run generate:normalize
$env:REPRO_MESSAGE = "second"; vp run generate:normalize
node ./scripts/check-normalized.mjs
There is also a convenience script if useful:
vp exec node ./scripts/repro.mjs
Observed behavior
On the second run, the first step executes uncached, rewrites src/generated/messages.ts, and the second step is replayed from cache.
Representative output for case 1:
$ vp exec node ./scripts/generate.mjs ⊘ cache disabled
$ vp fmt src/generated ◉ cache hit, replaying
Representative output for case 2:
$ vp exec node ./scripts/generate.mjs ⊘ cache disabled
$ node ./scripts/normalize.mjs ◉ cache hit, replaying
The final check then fails because the generated file contains fresh content from the first step but did not receive the second step's normalization/formatting.
Expected behavior
The second step should not be replayed when its previously tracked input file was modified by an earlier step in the same compound command. It should miss cache and run against the current file contents.
Notes
- This does not appear to be specific to
vp fmt; the plainnode ./scripts/normalize.mjsvariant reproduces the same behavior. - In local testing, replacing the first command with plain
node ./scripts/generate.mjsdid not reproduce the issue. - Including the changing value in the task's tracked
env/inputavoids this particular repro, but the concern here is intra-task filesystem changes between&&items. - This does not seem to be about restoring output files from cache. The file is rewritten by the preceding uncached step in the current run; the problem is that the following step is still replayed even though its read input has just changed.
A possible direction is that cache validation for later && items may need to account for filesystem writes from earlier items in the same task, especially when the earlier item is an expanded/cache-disabled vp exec invocation.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by cloning the linked repro, reviewing vite.config.ts and scripts/generate.mjs, scripts/normalize.mjs, and running both PowerShell reproduction cases. Trace the compound-command cache handling from the vp exec entry point; done means a later && step misses cache after an earlier step rewrites its input, with both final checks passing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, rust
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100