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.
dx
6 posts with the tag “dx”
Config in TypeScript, and why there are no named inputs
A vx.config.ts is a module: it can import a preset, spread it, compute a command. That one choice removes Turborepo's globalDependencies and Nx's namedInputs from the schema, because a language that composes does not need a schema that does.
One binary, nothing to install underneath
vx ships as one self-contained executable per platform. No Node to pick, no Bun to install, no daemon to start. npm install -D @vzn/vx gets you the binary; a release tarball gets you the same binary without npm.
Dev servers as graph nodes: readiness instead of sleep
The hard part of 'start the tests once the server is up' is knowing when it is up. vx watches a persistent task's output for a pattern, holds its dependents until the line appears, and tears the server down when the run ends.
Watch: a content gate, not an event storm
vx watch does not filter filesystem events against your input globs. It re-runs the graph and lets the cache key decide, which is tens of milliseconds for an irrelevant edit and exactly right for a relevant one.
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.