self-update

---
name: self-update
description: Update this junior-prod app to the latest published Junior release. Use when asked to self-update Junior, bump @sentry/junior and @sentry/junior-* dependencies, run safety checks, and open a draft PR.
---

## Workflow

### 1. Preflight

```bash
git status --short
git branch --show-current
```

Stop if `package.json`, `pnpm-lock.yaml`, or `pnpm-workspace.yaml` has unrelated uncommitted changes.

### 2. Inventory and target

Inventory direct Junior deps from `package.json`: `@sentry/junior` and `@sentry/junior-*`. Record package, current exact version, and dependency section. Keep all Junior deps on one version and do not move packages between sections.

Resolve the target:

```bash
pnpm view @sentry/junior dist-tags.latest
```

If user requests a specific version, use that. If already on latest, stop.

Verify the target exists for every inventoried package before mutating files:

```bash
pnpm view <package>@<target> version
```

Allow for npm security scanning and propagation delays after publication:

- If a version or tarball is missing, retry affected packages after 30, 60, and 120 seconds. Keep the same target; do not retry auth failures as publication delays.
- Confirm missing versions with cache-busted npm metadata and the direct version endpoint. Continue only when every package's exact target version and tarball are available.
- If still unavailable, leave app files unchanged and do not open an update PR. Report "not yet available on npm" with the target, affected packages, and checks. Missing packages alone do not prove a failed publish or a scanning delay; do not republish or cut another release.

### 3. Build release context

Summarize changes between `old_version` and `target_version` (exclusive of old, inclusive of target) from GitHub release notes. Do not read `CHANGELOG.md` or scrape PRs — release bodies carry the authoritative release context.

Tags match package versions with no `v` prefix (for example `0.107.1`):

Ask npm to resolve the semver range to the exact tags, then fetch only those releases:

```bash
pnpm view '@sentry/junior@><old_version> <=<target_version>' version --json
gh release view <version> --repo getsentry/junior --json tagName,name,body,publishedAt,url
```

Collect the corresponding release bodies. Stop if any expected GitHub release is missing; do not substitute another source. Save the target release's `publishedAt` as `target_published_at` for step 7. Save total change count, breaking changes (`Breaking Changes`, `!`, or `BREAKING CHANGE`), and config-relevant items (`config`, `plugins`, `nitro`, `createApp`, `runtime`, `credentials`, `egress`, `example`). If any breaking change exists, keep the PR draft and call out manual review, but continue the update.

### 4. Create or reuse branch

`build/update-junior-<target>`. All file mutations happen on this branch.

### 5. Sync `minimumReleaseAgeExclude`

If `pnpm-workspace.yaml` has a `minimumReleaseAgeExclude` list, ensure every Junior package from step 2 is covered by an exact entry or an existing package pattern. Add missing entries before `pnpm add`, but do not add exact entries already covered by `@sentry/*`. Append at end and preserve existing order.

### 6. Update deps (section-preserving)

Group `pnpm add` by dependency section:

```bash
pnpm add -E <deps-packages>@<target> ...
pnpm add -D -E <devDeps-packages>@<target> ...
pnpm add -O -E <optDeps-packages>@<target> ...
```

Do not manually edit versions in `package.json`. Do not use local `../junior` linking scripts.

### 7. Sync local config

If a new standalone `@sentry/junior-*` plugin package was added, add it to the app `plugins.ts` set passed to `defineJuniorPlugins(...)` and keep `juniorNitro({ plugins: "./plugins" })` pointed at that module. Exclude the base/runtime utility packages: `@sentry/junior`, `@sentry/junior-plugin-api`, `@sentry/junior-testing`.

```bash
node scripts/check-plugin-packages.mjs
```

Compare the consumer config with `apps/example` at `target_ref` to catch shape drift. Choose `target_ref` from the version bump commit, then the publish timestamp, then `origin/main` as approximate:

```bash
git clone --filter=blob:none --depth=200 https://github.com/getsentry/junior.git /tmp/junior-upstream
git -C /tmp/junior-upstream log --oneline -S'"version": "<target_version>"' -- packages/junior/package.json
git -C /tmp/junior-upstream rev-list -n 1 --before="<target_published_at>" origin/main
git -C /tmp/junior-upstream checkout <target_ref>
git diff --no-index -- /tmp/junior-upstream/apps/example/nitro.config.ts nitro.config.ts
git diff --no-index -- /tmp/junior-upstream/apps/example/plugins.ts plugins.ts
git diff --no-index -- /tmp/junior-upstream/apps/example/server.ts server.ts
```

Ignore app-local values. Apply only obvious low-risk fixes; put ambiguous drift in the PR body. For `package.json`, compare only build tooling (`nitro`, `jiti`, `typescript`), not plugin dependency lists or pins.

For `vercel.json`, do not normalize the whole file against the example. Use upstream diff-backed changes when possible:

```bash
git -C /tmp/junior-upstream diff <old_ref>..<target_ref> -- apps/example/vercel.json
```

Only act on Junior-owned deployment requirements proven by that diff or by release notes/docs. If `old_ref` is unavailable, target-only example entries are context, not proof; mark the review approximate and leave a manual review item when needed.

### 8. Verify

```bash
git diff --name-only
pnpm install --frozen-lockfile
pnpm check
pnpm typecheck
pnpm build
```

Expected changed files: `package.json`, `pnpm-lock.yaml`, optional `pnpm-workspace.yaml`, optional `nitro.config.ts`, optional `vercel.json`. Confirm every Junior dep is exactly `<target>`. If the frozen install fails, repair with `pnpm install --lockfile-only` and rerun. Fix update-related check failures; disclose pre-existing or environment failures.

### 9. Commit

```text
build(deps): Update Junior packages to <target>

Update the Junior runtime and plugin packages to <target> and refresh the pnpm lockfile.
```

Mention `minimumReleaseAgeExclude` sync if `pnpm-workspace.yaml` changed.

### 10. Push and open/update draft PR

Open a draft PR. Include version change, release summary with links to the GitHub releases, config comparison findings, optional workspace/plugin/vercel changes, and unexpected diffs. Do not put `Checks`, `Verification`, `Test plan`, or similar validation sections in the PR body; put local check results in the final user report only. Add **Manual review required** when breaking changes, unresolved config drift, approximate Vercel review, or failed checks exist.

When PR creation returns a subscribable resource hint, watch the PR for suggested review and CI events. After merge, if deployment follow-up is needed, use `github_getDeployment` for the merged commit and watch the suggested deployment events.

## Automatic updates from GitHub releases

When asked to keep an app current whenever Junior publishes a release, resolve `getsentry/junior` with `github_getRelease` (no tag) and create a durable event automation on `release.published`. The task instruction should load this skill and run the update against the published tag from the event's untrusted text / release payload. Prefer an event automation for ongoing automation; use a temporary watch only when following one manually initiated update.

## Stop conditions

- Any Junior package still lacks the target version or tarball after the bounded availability checks in step 2.
- Any npm version in `(old_version, target_version]` lacks a matching GitHub release.
- `pnpm install --frozen-lockfile` fails after repair.
- Checks fail for non-pre-existing, non-environment reasons and no safe config fix is available from step 7.
- `package.json` changed but `pnpm-lock.yaml` did not.
- Example app comparison reveals a breaking plugin signature change whose required values cannot be inferred from the existing consumer config.

From getsentry/junior at 1745a29, shown as plain text under its license: Apache-2.0 (permissive). The license text is in LICENSE.

• SKILL.md8.0 KB · c70ef9137a02

1 file, 8.0 KB in total. Each file has a sha256 in the pin's manifest; the first 12 characters are shown.