Plan a major dependency upgrade

Prepare for a major library or framework upgrade: breaking changes, code to update and a safe rollout order.

Change note: Initial version

Prompt

Help me plan an upgrade of {{package}} from {{from_version}} to {{to_version}}.

Project: {{project}}
How we use it (key features, patterns, wrappers): {{usage}}
Other related dependencies and runtime versions: {{related}}
Test coverage and release process: {{process}}

Please:
1. Summarize the breaking changes and deprecations between these versions that are likely to affect a project like mine. For each, say what I should search for in my code and what to change it to. Distinguish what you are confident about from what you recall less certainly, and tell me to confirm against the official changelog and migration guide before relying on those parts.
2. Check compatibility: required runtime, peer dependencies, plugins and tooling that may need upgrading first or at the same time.
3. Give the upgrade order: whether to go in one jump or via intermediate versions, and what to do before upgrading (cleanup, codemods, deprecation fixes on the old version).
4. Provide a checklist of grep patterns or commands to find affected code.
5. Define the verification plan: tests to run, manual checks, performance or bundle size comparison, and what to watch after release.
6. Rollback strategy and a split of the work into reviewable pull requests.
7. Estimate the effort and the top three risks.

Do not invent version numbers, option names or APIs. If you are unsure whether something changed, say so.

Variables

• {{package}}Packagetext

  Default: React Router

• {{from_version}}From versiontext

  Default: 5

• {{to_version}}To versiontext

  Default: 7

• {{project}}Projecttext

  Default: Single-page app with 120 routes, TypeScript, Vite

• {{usage}}How we use itlong

  Default: Route config in one file; nested routes; useHistory in about 40 components; custom Prompt wrapper for unsaved changes.

• {{related}}Related dependenciestext

  Default: React 18, Vite 5, Node 20

• {{process}}Tests and releasetext

  Default: Moderate unit tests, no end-to-end tests; weekly releases

Example output

**Breaking changes likely to matter (confirm in the official migration guide)**
| Area | Search for | Change |
|---|---|---|
| History hook | `useHistory` | Use `useNavigate`; `history.push(x)` becomes `navigate(x)` |
| Switch | `<Switch>` | Replaced by `<Routes>`; routes use `element` instead of `component` |
| Prompt | custom `Prompt` wrapper | Replace with `useBlocker`; behavior differs, retest by hand |
| Relative paths | nested routes with absolute links | Link resolution is relative by default now |

Less certain: data router APIs and future flags. Check the guide.

**Order:** go to the last 6.x release first, fix deprecation warnings there, then move to 7. Do not jump straight from 5.

**Find affected code**
```bash
grep -rn "useHistory\|<Switch\|component=" src | wc -l
```

**Verification:** unit tests plus a manual pass over unsaved-changes flows, since there are no end-to-end tests. Add smoke tests for the five most used routes first.

**PRs:** (1) add smoke tests, (2) 5 to 6, (3) 6 to 7.

**Risks:** the unsaved-changes wrapper, relative link behavior, plugin compatibility with Vite. Effort: 3-5 days.

Notes

Telling the model to separate confident knowledge from uncertain recall, and to point you to the official guide, reduces fabricated API details. Splitting the work into small PRs keeps the upgrade reviewable.