vx prune --production leaves out the workspace packages only dev dependencies pull in, and strikes them from the copied manifests and lockfile, so the image that runs your app installs frozen without them.
Pluginsvx prune copies one app and the workspace packages it needs, with the
lockfile cut to match. It follows every dependency, dev ones included,
because the build needs them. The image that only runs the built app does
not.
flowchart LR A[app] -->|dependencies| L[lib] A -.->|devDependencies| T[test-utils] L -.->|devDependencies| T P[vx prune app --production] --> O[out: app + lib]
$ vx prune app --docker --productionvx prune: 2 projects → out (json/ + full/) (production), bun.lock pruned app (packages/app) lib (packages/lib)test-utils stays behind. The copied package.json files and the lockfile
no longer name it, so the copy installs with a frozen lockfile under bun,
pnpm, npm and Yarn:
FROM oven/bun AS runCOPY out/json/ .RUN bun install --frozen-lockfile --productionCOPY out/full/ .CMD ["bun", "packages/app/dist/index.js"]A package that another field also names (dependencies, an optional or a
peer dependency) is installed in production and stays. Third-party dev
dependencies stay in the lockfile; the install’s own --production flag
skips them.
PluginsShip one app, not the whole monorepo
vx prune copies one project and the workspace packages it needs into a clean folder, with the lockfile cut to match. Your Docker build installs only what it ships, and a change in another app no longer busts the install layer.
PluginsYour run, on the pull request
One plugin line puts every vx run on GitHub: a job summary with the failure first, a check run on the commit, and a cache scope that keeps pull requests from writing what main reads.
PluginsA scheduler that learns from your runs
With @vzn/vx-schedule-history, vx starts the longest chain first and packs tasks by the memory they really used. vx history shows what it learned, task by task.