What the agent does
In an Express API like gothinkster/node-express-realworld-example-app, npm test does not call Jest directly: package.json maps test to nx test, build to nx build and start to nx serve, through an Nx 17.2.6 workspace (nx.json, project.json). The runtime dependencies are express ~4.18.1, express-jwt ^8.4.1, jsonwebtoken ^9.0.2, @prisma/client ^4.16.1, bcryptjs, cors, body-parser and axios; the dev side holds seven @nx/* packages pinned to 17.2.6, prisma ^4.16.1, jest ^29.4.1, ts-jest, typescript ~5.2.2, eslint ~8.48.0 and @types/node 18.16.9. The agent reads package-lock.json to see what is actually installed, then runs npm outdated.
It upgrades in linked sets. The seven @nx packages and nx move together with npx nx migrate, which also rewrites project.json and jest.preset.js when the Nx version needs it. prisma and @prisma/client always share a version, and after bumping them the agent runs npx prisma generate against src/prisma/schema.prisma (provider postgresql). express and @types/express move together; @typescript-eslint/parser and eslint-plugin move with eslint. The tilde ranges on express, typescript and eslint mean npm update leaves their minors alone, so the agent sets the new range on purpose.
The unit tests under src/tests/services and src/tests/utils (article, auth, profile and tag services) mock Prisma with jest-mock-extended in src/tests/prisma-mock.ts, so npm test needs no database. After each set the agent runs npm test and npm run build. Express 5 is a major with removed APIs; the agent reads the migration guide and keeps it only if the routes under src/app/routes compile and the tests pass, otherwise it records why and leaves express on 4.
Anything that fails is reverted in package.json and package-lock.json, and the failing command and its error stay in the record.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Upgrade this project's npm dependencies to their latest compatible releases. Move nx and every @nx/ package together with npx nx migrate, keep prisma and @prisma/client on one version and run npx prisma generate after bumping them. After each set run npm test and npm run build. For express 5, follow the migration guide and keep it only if both pass. Revert any set that fails and record the error. Open one pull request listing each bump with its old and new version and each skipped upgrade with the error that blocked it.",
"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 package.json and package-lock.json, and the Nx configuration files when nx migrate rewrote them. Its description groups the bumps the way they were made (Nx, Prisma, Express, lint and types, the rest) with old and new versions, then lists each skipped upgrade with the failing command and error. Any change to route code that an upgrade required is listed with the reason.
Because the unit tests mock Prisma, they do not prove the new Prisma client talks to a real database. A reviewer runs the e2e project or the app against a Postgres instance before merging a Prisma major, and reads the nx migrate output for changed defaults. Every command and its output is in the session transcript.
Run it on every Monday morning
Send this request on a weekly schedule from a cron job or a scheduled GitHub Actions workflow, naming the repository in resources. Small weekly steps keep the Nx and Prisma migrations to one version at a time.
Set a webhook on the API key to hear when the turn finishes; your handler gets run.completed with a session_url and can post the pull request where your team reviews it.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
Upgrading an Nx-based Express app is several tools at once: nx migrate, Prisma client generation, Jest through ts-jest and a TypeScript build. In a Rush sandbox the agent installs from the lockfile on a clean machine, runs each step, and keeps every npm and nx command with its output, so a reviewer sees why a set was left out.
Dependency bots raise separate pull requests for nx and each @nx package, which cannot pass on their own. Here they arrive as one tested change. If you run several Node services, each can get its own run at the same time, within the key's concurrency limit.
Frequently asked questions
Will it move us to Express 5?
Only if the routes compile and the tests pass after following the migration guide. Otherwise express stays on 4 and the pull request explains what failed.
Does npm test need a database?
Not in this project: the service tests replace the Prisma client with a deep mock. That keeps the run simple but means a Prisma major should also be checked against a real Postgres before merge.
Why use nx migrate instead of npm install?
Nx packages must share one version, and nx migrate also applies the configuration changes each Nx release needs. Installing them by hand can leave project.json out of date.
Can I use pnpm or Yarn?
Yes. The agent uses the lockfile it finds. This project has package-lock.json, so it uses npm.