# Upgrade Nuxt Dependencies Every Week

Yes. Each week a Rush agent upgrades your Nuxt app's packages, runs Vitest, lint and vue-tsc, reverts what breaks and opens one tested pull request.

[Run this on Rush](https://cloud.getrush.ai/run/upgrade-dependencies-weekly/nuxt/), in a Project that has your repository.

## What the agent does

In a Nuxt app like elk-zone/elk, package.json names pnpm@11.6.0 as its packageManager and pnpm-lock.yaml holds the versions, so the agent enables that pnpm through corepack, as .github/workflows/ci.yml does, rather than using npm. The dependencies include nuxt ^4.4.2, vue ^3.5.4, vite ^7.1.7, pinia ^3.0.3 with @pinia/nuxt, @nuxtjs/i18n ^10.1.0, @unocss/nuxt, @vueuse/nuxt ^14.1.0 next to @vueuse/core ^13.9.0, masto ^7.12.0 and vite-plugin-pwa. Every @tiptap/* package is pinned to exactly 2.27.2.

pnpm-workspace.yaml shapes what an upgrade may do. Its overrides force vitest to 4.1.9, vue to ^3.5.4 and nuxt-component-meta to 0.17.2, so a bump in package.json alone does not move those; the agent changes the override too, or leaves it. trustPolicy is no-downgrade, with a trustPolicyExclude list that names each @tiptap package at 2.27.2, so moving tiptap means updating that list in the same commit or pnpm refuses the install. The workspace also includes the docs package, which has its own dependencies.

The checks come from ci.yml: pnpm install --frozen-lockfile, pnpm nuxi prepare, pnpm test:ci (vitest run), pnpm lint (eslint with @antfu/eslint-config) and pnpm test:typecheck (vue-tsc -b --noEmit). vitest.config.ts uses defineVitestProject from @nuxt/test-utils with tests/setup.ts and mocks IndexedDB and IntersectionObserver, and the tests in tests/nuxt (content-rich, html-parse, html-to-text) compare against snapshots in tests/nuxt/__snapshots__. The agent runs all five after each group.

Groups are upgraded together: nuxt with @nuxt/test-utils and @nuxt/devtools; vue with vue-tsc and @vue/test-utils; every @tiptap package at once; the @vueuse packages onto one major; unocss. A group that fails is reverted in package.json, pnpm-lock.yaml and pnpm-workspace.yaml. A snapshot that changes is not updated to pass; it is reported, because a changed parse of a Mastodon post is a behavior change.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Upgrade this project's dependencies to their latest compatible releases with the pnpm version packageManager names, one group at a time: nuxt with @nuxt/test-utils and @nuxt/devtools; vue with vue-tsc and @vue/test-utils; all @tiptap packages together, updating trustPolicyExclude; the @vueuse packages onto one major; then the rest. Update pnpm-workspace.yaml overrides when a bump needs it. After each group run pnpm nuxi prepare, npx vitest run, pnpm lint and pnpm test:typecheck. Do not update snapshots to make tests pass. Revert any group 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"
    }
  ]
}
```

1. **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.
2. **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.
3. **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, pnpm-lock.yaml, and pnpm-workspace.yaml where an override or trust exclusion had to move, plus docs/package.json if the docs workspace shared a bumped package. The description lists every bump with old and new versions by group, notes each override it changed, and lists each group left out with its failing command. Any snapshot that differed is quoted, not overwritten. ci.yml runs the same install, tests, lint and type check on the pull request.

A reviewer reads the Nuxt and tiptap release notes if either moved, runs the app with pnpm dev:mocked to click through the timeline and composer, and checks that the PWA still builds with pnpm build.

## Run it on every Monday morning

Nuxt modules, Vue and Vite each release on their own schedules, so a Nuxt app's lockfile drifts every week. Have a scheduler send this request each Monday with the repository in resources, and each pull request carries only that week's tested changes.

A webhook URL set on the API key receives run.completed when the turn finishes; the handler can read session_url and post the result to your team.

## Why run it on Rush?

Overrides, a trust policy and a workspace make a Nuxt upgrade more than a version bump: an install can be refused before any test runs. In a Rush sandbox the agent works through those failures with the exact pnpm the project pins, runs Vitest, ESLint and vue-tsc after each group, and keeps every command with its output in the transcript.

Seventeen tiptap packages as seventeen pull requests, each failing the trust check, is noise. One pull request a week that moves related packages together and explains each holdout is something a reviewer can finish. Several Nuxt apps can run this at the same time.

## Frequently asked questions

### My project uses npm, not pnpm. Does that change anything?

The agent uses the package manager the project declares. Elk names pnpm@11.6.0 in packageManager, so it uses pnpm there; a project with package-lock.json gets npm install and npm update, and the overrides live in package.json instead.

### What happens to pnpm overrides?

The agent changes an override only when a bump needs it, and lists every override change in the pull request so a reviewer sees what was forced and why.

### Will it update my Vitest snapshots?

No. A snapshot that changes after an upgrade is reported with its diff, and the upgrade that caused it is left out unless you say the change is expected.

### Does it touch the docs workspace?

Only where a shared package moves. The docs package in pnpm-workspace.yaml has its own dependencies, and the agent keeps the lockfile consistent across both.