with one click
batch-deps-upgrade
// Batch all open Dependabot dependency upgrade PRs into a single PR
// Batch all open Dependabot dependency upgrade PRs into a single PR
| name | batch-deps-upgrade |
| description | Batch all open Dependabot dependency upgrade PRs into a single PR |
| disable-model-invocation | true |
Batch all open Dependabot dependency upgrade PRs into a single PR for this repository.
Run: gh pr list --repo XRPLF/xrpl.js --label dependencies --state open --limit 500 --json number,title,headRefName,body,url
Parse each PR to extract package names and versions. Dependabot PRs come in two formats:
Bump <pkg> from <old> to <new> — parse from titlebump <pkg1> and <pkg2> with no versions — parse from PR body, which contains a structured list of package updates with version rangesIf any PR can't be parsed from either title or body, flag it for manual review. Build a table of all proposed upgrades. Report the table to the user before proceeding.
npm ls <pkg> and check if any workspace package pins a peer dep that would block the upgrade (e.g., @xrplf/eslint-config@^3 requires eslint@^9, blocking eslint 10). Mark these as Skipped (peer dep conflict: npm update <pkg> to update within semver rangenpm install to update package-lock.json. Do NOT delete package-lock.json and regenerate from scratch — this can change hoisted dependency resolution and break builds even when no versions changed.## Unreleased in that package's HISTORY.md.Run the full test suite in order:
docker rm -f xrpld-service 2>/dev/null || truedocker run --detach --rm --publish 6006:6006 --volume "$PWD/.ci-config:/etc/opt/xrpld/" --name xrpld-service rippleci/xrpld:develop --standaloneSECONDS=0
until nc -z localhost 6006 || [ $SECONDS -gt 120 ]; do sleep 2; done
if ! nc -z localhost 6006; then
echo "Error: xrpld did not start within 120s"
docker logs xrpld-service
exit 1
fi
npm run test:integration && npm run test:browserdocker stop xrpld-service (auto-removed via --rm)If any step fails, attempt to fix the breaking change with code modifications before rolling back. Common patterns:
new BigNumber(val) calls in try-catch where the code previously checked for NaN.transformIgnorePatterns exclusions in jest.config.base.js so Jest can parse ESM imports.let buf: Uint8Array = ... instead of let buf = ...).Only roll back and mark as Skipped if:
If a failure persists after investigation and you cannot identify a fix, roll back the upgrade and mark it as Skipped. Re-run validation until green.
Do NOT commit or create a PR. Instead, generate the following outputs for the human to use:
Code changes note — write a markdown file (.claude/skills/batch-deps-upgrade/code-changes.md) documenting every non-package.json source code change, explaining what broke, why, and the minimal fix applied.
Commit message — output a concise commit message the human can copy-paste into git commit -m "...". Format: chore(deps): quarterly batch dependency upgrade YYYY-QN followed by a brief summary of upgrades, skips, and removals.
PR description — write a markdown file (.claude/skills/batch-deps-upgrade/pr-description.md) following the repo's PR template (.github/pull_request_template.md):
HISTORY.md entry was added in Step 2.6.No if the major version number did not change. Otherwise Yes plus a link for each major version crossed. For example, 7.x → 9.x yields Yes ([v8](url), [v9](url)). Each link should point to the package's release notes or changelog for that major version. Verify each link returns HTTP 200 and has meaningful content (e.g., curl -sL -o /dev/null -w "%{http_code}" <url>); if a package doesn't publish per-version GitHub releases (e.g., TypeScript sometimes skips x.0.0/x.0.1 tags, bignumber.js puts details in CHANGELOG.md), fall back to the CHANGELOG.md file or the closest valid release tag.