What the agent does
A Vue 3 starter like antfu-collective/vitesse keeps almost no versions in package.json. Every dependency there says catalog:frontend, catalog:build, catalog:dev or catalog:types, and the real ranges live in pnpm-workspace.yaml: the frontend catalog holds vue ^3.5.43, vue-router ^5.3.1, pinia ^4.0.3, vue-i18n ^11.4.13 and @vueuse/core ^15.0.0, and the build catalog holds vite ^8.3.3, vite-ssg ^28.3.0, unocss ^66.10.5 and the unplugin packages. packageManager pins pnpm@10.30.2. So the agent edits catalog entries, not package.json, and lets pnpm install rewrite pnpm-lock.yaml.
The workspace file carries settings the agent keeps as they are. trustPolicy is no-downgrade, with two named exceptions (a Workbox rollup plugin and semver 6.3.1) that each have a comment explaining why. onlyBuiltDependencies allows only cypress, esbuild and simple-git-hooks to run install scripts, and .npmrc sets shamefully-hoist=true. If an upgraded package needs another build script or lacks the provenance trustPolicy expects, the agent leaves that package at its current version and quotes pnpm's message, rather than adding exceptions on its own.
The project already has an upgrade command: pnpm up runs taze major -I, an interactive tool for picking major bumps. The weekly job wants compatible releases, so the agent skips that script, checks each catalog entry's newest release inside its current range, and writes the new ranges into the catalogs. Then it runs the CI checks. The test script is vitest, which watches in a terminal, so the agent uses pnpm test --run for test/basic.test.ts and test/component.test.ts, then pnpm run build (vite-ssg build), pnpm run lint and pnpm run typecheck (vue-tsc --noEmit).
The engines field accepts Node ^22.22.2, ^24.15.0 or 26 and later, and the CI workflow's test job runs on both 22.x and 24.x. The agent runs the unit tests and the build on both, since a vite or vite-ssg release that drops Node 22 would pass on one and fail on the other. Any package that breaks a check is found by reverting catalog entries in halves until one is left, set back to its old range, and recorded with its error. The Cypress test in cypress/e2e/basic.spec.ts needs a browser and a running preview; the agent runs it when it can and says if it did not.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Upgrade the npm dependencies to the latest compatible versions with pnpm. Versions live in the catalogs in pnpm-workspace.yaml, so update the catalog entries, not package.json, and keep trustPolicy, its exceptions and onlyBuiltDependencies unchanged; if an upgrade needs one of those changed, leave it out and quote pnpm's message. Use the pnpm version in packageManager. Run pnpm install, pnpm test --run, pnpm build, pnpm lint and pnpm typecheck before changing anything for a baseline, and run pnpm test --run and pnpm build on both Node 22 and Node 24 after the upgrade, plus lint and typecheck. Leave out any upgrade that breaks the build or tests and say why. Open a pull request with one line per bump.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The pull request changes pnpm-workspace.yaml and pnpm-lock.yaml. One line per package gives the catalog it belongs to and the old and new range, so a reviewer can see at a glance whether a frontend runtime package or only a build tool moved. Upgrades that were left out each have the command that failed, the Node version it failed on and the error, and anything held back by trustPolicy or onlyBuiltDependencies is listed with pnpm's own message.
Before merging, a reviewer starts pnpm dev, visits a couple of pages to check file-based routing, layouts and i18n still work, and checks that the CI workflow's lint, typecheck, test (Node 22.x and 24.x) and Cypress jobs pass on the pull request. Major releases that taze major would offer are out of scope for this run and are listed for later.
Run it on every Wednesday
Midweek is a common choice because it leaves days to review before a Friday release. Your scheduler sends POST /o/{org}/sessions with this request each Wednesday, one call per Vue repository, each with an Idempotency-Key for that repository and week.
The webhook configured on the API key receives run.completed with the session_url. Read the session, pick up the pull request link, and assign it to a reviewer. Catalog entries that were held back stay where they are and get another try the next Wednesday.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
This job runs the same tests and build twice, on two Node versions, and repeats them for each round of narrowing down a failure. A Rush sandbox gives the agent its own machine with both Node versions available, its own pnpm store and the output of every command kept in the session, so nobody has to switch Node versions on their own laptop to check an upgrade.
Catalog-based projects are awkward for bots that edit package.json, and a pull request that bumps a catalog entry without running vite-ssg build tells you little. The agent edits the catalogs directly, tests the result the way CI does, and opens one pull request without the bumps that failed. Many repositories can run it in parallel, up to the key's concurrency limit.
Frequently asked questions
Does it understand pnpm catalogs?
Yes. In vitesse every dependency is catalog: something, so the agent reads and edits pnpm-workspace.yaml. Changing a catalog entry updates every place that uses it, which keeps versions consistent.
Will it run taze major like pnpm up does?
No. taze major -I is interactive and offers new majors, which is a choice for a person. The weekly run stays within the current ranges and lists any available majors in the pull request.
Why test on two Node versions?
The package's engines field allows Node 22 and 24, and the CI test job runs both. A build tool that drops Node 22 would pass on 24 alone, so the agent checks both before keeping an upgrade.
Will it change trustPolicy or allow more install scripts?
No. Those settings are security decisions the maintainers made. An upgrade that needs them changed is left out and named, with pnpm's message, so a person can decide.