Upgrade a dependency with breaking changes
Bump a major version and let Pier handle the fallout: read the changelog, find every broken call site, update them, and get the build passing again.
› Upgrade the http client from v3 to v5. The .request() signature changed. Fix all call sites.
● v5 moved options into a single config object and renamed .request to .send. Let me find every call site.
● Ran rg -n '\.request\(' --type ts | wc -l
└ 17
● 17 call sites across 6 files. Migrating each to .send with the new config shape, build between batches.
● Edited src/api/client.ts (+1 -1)
● Ran pnpm build && pnpm test
└ build: success
test: 132 passed
All 17 sites migrated
● All call sites on the v5 API, build clean, tests pass. One spot used a removed retry-callback; I left a note on that line for your call. Review the diff?
- 01Tell Pier which dependency to upgrade and to what version.
- 02The agent reads the changelog or release notes for the breaking changes.
- 03It finds every call site affected and updates them to the new API.
- 04It runs the build and tests until the upgrade is fully green.
Major version bumps are postponed for a reason: the install is one command, but the cleanup is a scavenger hunt. A renamed method here, a changed default there, an argument that moved from positional to an options object, each one a compile error or, worse, a silent behaviour change. Pier turns the scavenger hunt into a tracked task. It reads the release notes to learn what actually broke, then searches the repo for every place you use the affected APIs.
It updates them in batches and runs the build between each, so you are never staring at two hundred errors at once. Where a change is mechanical, it just applies it; where the new API genuinely behaves differently, it pauses and flags the decision for you rather than guessing. The outcome is a single reviewable changeset that takes you from the old version to the new one with the suite green, instead of a half-finished branch you abandon.
It runs on the same find-everything, fix-in-batches approach as a codebase-wide migration, and it is just as cheap, since most of the effort goes into reading. See cost per task for the numbers.
