Plan a major dependency upgrade

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

LLazyPrompt(@lazyprompt)CodingPlanWorks with any model
No ratings yetSign in to rate
Save 0 Fork Report
Prompt template
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.
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.

Why it works

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.

Licensed CC0 (public domain) Version 1 · history