Upgrade npm Dependencies in a Fastify API

In fastify/demo the agent reads package.json and finds fastify ^5.10.0 with @fastify/autoload, @fastify/env, @fastify/session, @fastify/cookie, @fastify/swagger, @fastify/under-pressure and the rest of the official plugins, knex with mysql2, postgrator for the SQL migrations under migrations, typebox ^1.3.6 with the TypeBox type provider, and on the dev side typescript ~6.0.3, @types/node ^26.1.1, tsx, c8, glob and neostandard for eslint. There is no lockfile: .gitignore lists package-lock.json, pnpm-lock.yaml, yarn.lock and bun.lockb, and .npmrc sets ignore-scripts=true and min-release-age=7. That changes what an upgrade means here: every install already floats to the newest version inside each range, so the job is raising the ranges themselves, and npm will not take a version younger than seven days.

The checks are the ones ci.yml runs on Node 22 and 24 with a mysql:8.4 service: npm i --ignore-scripts, npm run build -- --noEmit, npm run lint, a generated COOKIE_SECRET, an empty .env for the scripts that pass --env-file=.env, then npm run db:migrate and npm run test with MYSQL_HOST, MYSQL_DATABASE test_db, MYSQL_USER test_user, CAN_SEED_DATABASE=1 and RATE_LIMIT_MAX=4 in the environment. The test script seeds the database and runs c8 over glob -c "tsx --test" "./test/**/*.ts", so the suite is node:test rather than a separate runner. test/helper.ts builds the app through fastify-plugin with skipOverride and adds login and injectWithLogin helpers that post to /api/auth/login and read the cookie named by this.config.COOKIE_NAME; the specs cover cors, env, the error and not-found handlers, rate limiting, the scrypt password plugin and the home, auth, users and tasks routes.

The agent starts MySQL 8.4 in the sandbox as docker-compose.yml describes, exports the same variables as CI, runs db:migrate and the full baseline, then runs npm outdated. For each package it raises the range with npm install @latest, one at a time or in small groups, and reruns build, lint and test. Because the test suite exercises @fastify/env's schema, @fastify/rate-limit's limit of 4 and the session cookie, a plugin that changed its options or its error shape fails a named test rather than passing quietly.

A bump that fails goes back to its previous range with the failing test name and error kept for the pull request. Majors in the @fastify family are applied only when the Fastify core version they require is already in place, and the typebox 1.x line is checked against the type provider it pairs with. Because there is no lockfile to commit, the pull request is a package.json diff, and its description states the exact versions the sandbox resolved so a reviewer knows what was tested.

The pull request changes package.json only, since the repository keeps no lockfile. The description has one line per package with the old range, the new range and the version npm resolved in the sandbox, then the bumps left out with the command and error that failed. A package held back by min-release-age is listed with the newer version it will reach once that version is old enough.

A reviewer checks that the CI matrix passes on both Node versions, reads the fastify and @fastify lines first because plugin majors tend to change option names, and checks the typebox line against the type provider. The session record holds the MySQL start, the baseline, every npm install and every test run, so an excluded package can be retried in a follow-up message to the same session.

A scheduled workflow sends POST /o/{org}/sessions with this request and your repository in resources, with the org key as the bearer token and an Idempotency-Key built from the repository name and the week, so a re-run of the workflow returns the run already started.

Put a webhook URL on the key. When the turn finishes your endpoint receives run.completed with session_url, reads the pull request link from the session and posts it to the backend channel for the week's review.

Testing a Fastify upgrade honestly means a MySQL instance, migrations, seeds and a full node:test pass for every group of bumps, which is slow on a laptop and leaves containers and environment variables behind. In a Rush sandbox the agent runs that loop on its own machine as many times as the upgrade needs, with each command's output kept.

A bot that opens one pull request per package leaves the team to find which of a dozen plugin bumps broke the session cookie test. The agent opens one pull request, already run against the suite, with the failing bumps taken out and named, and the same request can run against every Fastify service you maintain at once, up to the key's concurrency limit.

Why is there no lockfile diff?

Does it respect min-release-age?

Does it need MySQL to run the tests?

Will it move Fastify or a plugin to a new major?