voidzero-dev / voidzero-dev/vite-task
Cached compound command can replay a later step after preceding vp exec rewrites its input
Nessuno ha ancora preso questa issue.
- Lingua principale
- Rust
- Stelle
- 466
- Fork
- 42
- Merge medio
- 1g 15h
- PR unite (30g)
- 19
Descrizione
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.
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Inizia clonando il repro collegato, esaminando vite.config.ts, scripts/generate.mjs e scripts/normalize.mjs ed eseguendo entrambi i casi di riproduzione PowerShell. Traccia la gestione della cache dei comandi composti a partire dal punto di ingresso vp exec; il lavoro è completato quando un passaggio && successivo non trova la cache dopo che un passaggio precedente ha riscritto il proprio input, con entrambi i controlli finali superati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- node.js, rust
- Ambito
- build-system, tooling
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 48/100