Skip to content
vxvx
GitHubBlueskydev.toRSS

// the vx blog

design

Posts tagged design.

RSS

Every task has a key

A task you never cache still has a key. Change its inputs and every cached task after it runs again, so you never get a build made for old inputs.

What a run does not do

A run does no cleanup at exit, never walks the shared store, and shows no "time saved" it did not measure.

What vx is, and what it refuses to be

vx runs and caches your task graph, correctly, and nothing else. How a run works, and what will never be inside.

There was no choice on the market

Turborepo runs and caches. Nx adds a platform. vx is the runner with open plugin points, and nothing behind a paid cloud.

Performance, modularity, extensibility. In that order.

Three priorities in a fixed order settle every design choice in vx: performance, then modularity, then extensibility. Nine rules follow.

No daemon, and still quick when nothing changed

vx has no background process watching your files. A run with nothing to do stays quick, and it can never act on a stale view of the tree.

One command per task; the shell is the API

A vx task is one shell command. That one rule is why remote runs, the sandbox and cache replay all work without special cases.

A plugin fills one stage, often in under 25 lines

vx is a pipeline with a named hook at every stage. A plugin fills only the stage it needs, and most example plugins are under 25 lines.

Running here is not a plugin

Your machine is always the last place a task can run, and the local cache is always asked first. A dead remote never breaks a build.

Turborepo, Nx and other product names are trademarks of their owners. vx is not affiliated with or endorsed by them.