self-update

Workflow

1. Preflight

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:

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:

pnpm view <package>@<target> version

Allow for npm security scanning and propagation delays after publication:

• 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. Do not retry auth failures as publication delays.
• If any package is missing, leave app files unchanged. Call watchTimer with after_ms: 900000 (15 minutes). Start its intent with Run $self-update for target <target>, so the timer Turn loads this skill, then name the missing packages and the wait number (for example wait 1 of 4). After watchTimer succeeds, end the Turn without a message in a separate call: in an Automation run, call finishAutomationRun with no_action; otherwise call noReply. If watchTimer fails, report the failure instead. When the timer fires, check the same target again.
• Wait at most 4 times (one hour). If a package is still missing after the fourth wait, 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:

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, 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:

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.

node scripts/check-plugin-packages.mjs

Compare the consumer config with apps/example at target_ref to catch shape drift. Call github_cloneRepository with repo: "getsentry/junior", directory: "repos/junior-upstream", and allow_ad_hoc: true. Do not switch to a junior Workspace: the switch replaces the sandbox and removes this app checkout. Use the returned path as <upstream>. Choose target_ref from the version bump commit, then the publish timestamp, then origin/main as approximate:

git -C <upstream> fetch --deepen=200 origin main
git -C <upstream> log --oneline -S'"version": "<target_version>"' -- packages/junior/package.json
git -C <upstream> rev-list -n 1 --before="<target_published_at>" origin/main
git -C <upstream> checkout <target_ref>
git diff --no-index -- <upstream>/apps/example/nitro.config.ts nitro.config.ts
git diff --no-index -- <upstream>/apps/example/plugins.ts plugins.ts
git diff --no-index -- <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:

git -C <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

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

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 PR

Open the PR ready for review, not as a draft. If an existing update PR is a draft, mark it ready for review. 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.

Stop conditions

• Any Junior package still lacks the target version or tarball after one hour of waits 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.