Fresh `vp create monorepo` requires 2–3 `vp run ready` invocations before cache stabilizes

[fengmk2]

Summary

After scaffolding a fresh monorepo with vp create vite:monorepo, the first vp run ready runs everything fresh (expected), but the second invocation also cache-misses — only the third invocation reaches 100% cache hit. The cache test in .github/workflows/test-vp-create.yml (the Verify cache (monorepo only) step) expects 100% on the second run.

This was previously masked on main: the scaffolded packages/utils/package.json declares "vite-plus": "^0.1.20". When the root vite-plus version was 0.0.0 (main's dev version), it did not satisfy ^0.1.20, so npm refused to hoist and pre-populated packages/utils/node_modules/ at install time. The cache test happened to pass because packages/utils/node_modules/ already existed before the first vp run ready. On release branches (e.g. release/v0.1.22) the root version satisfies ^0.1.20, npm hoists, and packages/utils/node_modules/ is empty until vitest/tsdown create it on the first run — which then trips the cache-fingerprint diff on the second run.

Discovered while debugging CI failures on #1637.

Reproduction

# From this repo (release/v0.1.22 or any branch with a non-0.0.0 version):
pnpm build
cd packages/core && pnpm pack --pack-destination ../../tmp/tgz && cd -
cd packages/test && pnpm pack --pack-destination ../../tmp/tgz && cd -
cd packages/cli  && pnpm pack --pack-destination ../../tmp/tgz && cd -

TGZ=$PWD/tmp/tgz
VP_VERSION="file:$TGZ/vite-plus-0.1.22.tgz" \
VP_OVERRIDE_PACKAGES="{\"vite\":\"file:$TGZ/voidzero-dev-vite-plus-core-0.1.22.tgz\",\"vitest\":\"file:$TGZ/voidzero-dev-vite-plus-test-0.1.22.tgz\",\"@voidzero-dev/vite-plus-core\":\"file:$TGZ/voidzero-dev-vite-plus-core-0.1.22.tgz\",\"@voidzero-dev/vite-plus-test\":\"file:$TGZ/voidzero-dev-vite-plus-test-0.1.22.tgz\"}" \
VP_FORCE_MIGRATE=1 \
vp create vite:monorepo --directory /tmp/repro --no-interactive --no-agent --package-manager npm

cd /tmp/repro
vp run ready   # 0/5 cache hit (utils#test "modified its input")
vp run ready   # 3/5 cache hit (60%) — `test-project#ready` and `utils#test` still miss
vp run ready   # 5/5 cache hit (100%)

vp run --last-details on the second invocation

[1] test-project#ready: $ vp check
    → Cache miss: 'node_modules' added in 'packages/utils'
[2] utils#test: ~/packages/utils$ vp test
    → Cache miss: no previous cache entry found
[3] website#build: ~/apps/website$ tsc            ◉ cache hit
[4] website#build: ~/apps/website$ vp build       ◉ cache hit
[5] utils#build:   ~/packages/utils$ vp pack      ◉ cache hit

Two distinct cache misses, both rooted in packages/utils/node_modules/:

1. test-project#ready: the root vp check task fingerprints packages/utils/ directory entries. First vp run ready creates packages/utils/node_modules/ (vitest's deps optimizer + tsdown's temp dir); the directory's appearance reads as an input change on the next run. Eventually settles on run feat: basic command implementation #3.
2. utils#test: vitest's deps optimizer writes inside packages/utils/node_modules/.vite/, which fspy observes as read-then-write — vite-task refuses to cache. This one never settles via warm-up alone; even on run feat: basic command implementation #3 it caches only because the read/write pattern stops triggering new fspy events once the optimizer's cache is warm.

Suggested fixes

• Best: vite-task should not treat the creation of node_modules/ (or node_modules/.vite{,-temp}/) as a cache-invalidating input change. These are runtime caches, not source.
• Workaround: the scaffolded monorepo's vite-task config could explicitly exclude **/node_modules/** from default inputs.
• Test-side band-aid (not recommended for the long term): insert a warm-up vp run ready in the workflow before the "Verify cache" step. Locally this still needs two warm-ups to settle, so the test would need to assert the 3rd run, not the 2nd — which papers over the actual UX bug.

Impact

• Any user running vp run ready on a freshly scaffolded monorepo will see two non-cached runs before cache kicks in. Worth fixing for first-impression UX, not just for the CI signal.
• Unblocks release: v0.1.22: Security Patch, Parallel Global Install & Scaffold Polish #1637 if either the cache test is relaxed or the underlying input-tracking is fixed.