Your cache key is already in git's index
Hashing inputs is the cost every cache pays. vx pays it once, in git, and reads the blob ids back. Here is how the key is derived, part by part, and why a commit never flips it.
caching
7 posts with the tag “caching”
Configs are programs. Hash what they evaluate to.
A vx.config.ts can import a preset, compute a command, read a constant from another file. The cache key sees the evaluated object, so all of that participates in the key. Static JSON tools cannot see it at all.
The tree is exactly the snapshot
Turborepo and Nx restore outputs on top of whatever is already there. vx wipes the declared outputs first, on a miss and on a hit, so the tree after either is the cached snapshot and nothing else. Stale files cannot survive.
Cascade through dependencies by folding input keys, never outputs
When a library changes, its dependents must re-key. There are two ways to carry that change downstream, and vx tried both. It settled on the one that lets every key in the graph be known before anything runs.
Why did this re-run?
You changed one file and expected one rebuild; you got twelve. Most tools say 'miss' and stop. vx keeps the per-component fingerprints behind every key, so vx why names the component that moved.
A lockfile bump should re-key two tasks, not sixty
Every monorepo tool folds the lockfile into every key, so pnpm update invalidates the world. @vzn/vx-lockfile parses the lockfile and keys each task on its own project's dependency closure. In vx's own repo that turned 59 re-keyed tasks into 2.
Flaky is a claim only declared inputs can back
vx names a task flaky only when its exact cache key has both passed and failed on record, or it needed a retry this run. A failure on inputs that never passed is a break, not a flake. No service, no upload: the local run history is enough.