feat: add automated dependency bump checker and changelog validator

[cryptodev-2s]

Description

Adds a new check-deps command to automatically detect, validate, and update dependency bump entries in CHANGELOGs.

Usage

# Detect and validate
yarn check-dependency-bumps

# Auto-fix
yarn check-dependency-bumps --fix --pr 1234

Key Features

• Detects dependency bumps from git diffs in package.json files
• Validates exact versions in changelog entries (catches stale entries)
• Auto-updates changelogs with --fix flag
• Preserves PR history when bumping same dependency multiple times
• Release-aware - adds entries to ## [X.Y.Z] section when package version changes, or [Unreleased] otherwise
• Repository agnostic - reads repo URL from package.json

Example:

# Before (PR #7007):
- Bump `@metamask/transaction-controller` from `^61.0.0` to `^61.1.0` ([#7007](...))

# After fix (PR #1234):
- Bump `@metamask/transaction-controller` from `^61.0.0` to `^62.0.0` ([#7007](...), [#1234](...))

Implementation

New files:

• src/check-dependency-bumps.ts + tests (24 tests)
• src/changelog-validator.ts + tests (27 tests)

Modified:

• src/command-line-arguments.ts - Added check-deps command
• src/main.ts - Command routing
• Updated test files for command structure

Coverage: 100% (statements, branches, functions, lines) - 340 passing tests

Testing in MetaMask/core

# Build tool
cd /path/to/create-release-branch && yarn build

# From core
cd /path/to/core
git checkout -b test-dep-bumps

# In one or more packages, modify package.json to:
# - Bump some dependencies
# - Bump some peerDependencies  
# - Bump some devDependencies (to verify they're correctly excluded)
# - Change the package version (to test release detection)

git add . && git commit -m "Test: bump dependencies"

# Validate
node /path/to/create-release-branch/dist/cli.js check-deps

# Fix without PR number
node /path/to/create-release-branch/dist/cli.js check-deps --fix

# Fix with PR number
node /path/to/create-release-branch/dist/cli.js check-deps --fix --pr 4532

# Validate with github-tools (https://github.com/MetaMask/github-tools)
cd /path/to/github-tools
yarn run changelog:check "/path/to/core" "main" "4532"

---

Note

Introduce check-deps CLI to detect dependency bumps from git diffs, validate CHANGELOG entries, and optionally auto-update them.

• CLI
  • Add check-deps subcommand (via yargs) to analyze package.json diffs between refs and print JSON results.
  • Route commands in main to support release and new check-deps; guard initial-parameters for release-only.
• Changelog validation/updating
  • New src/changelog-validator.ts: exact-match validation against Unreleased or specific release sections; auto-add/update entries; preserve/merge PR numbers; mark peerDependencies as BREAKING; support placeholder PRs.
  • New src/check-dependency-bumps.ts: parse diffs, detect dependencies/peerDependencies bumps (skip dev), dedupe, detect package version bumps for release-aware targeting, resolve repo URL, and invoke validator/updater.
  • Shared types in src/types.ts.
• Tests
  • Extensive unit tests for diff parsing, validation, and updating logic; command routing in main and CLI args.
• Docs/Changelog
  • Update CHANGELOG.md with new command and usage.

^{Written by Cursor Bugbot for commit 88d116a. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Grammatical pluralization gap in changelog updates

Missing singular/plural handling for the "added" count in the combined update message. When both updating and adding entries, the message always uses "changelog entries" (plural) even when only 1 entry is added. The message should use conditional pluralization like: ${entriesToAdd.length} changelog ${entriesToAdd.length === 1 ? 'entry' : 'entries'} to be grammatically correct and consistent with other messages in the codebase (see lines 340 and 420).

 

[mcmire]

@cryptodev-2s I haven't had time to review this yet, but I have one initial thought:

Should we rename check-deps to validate? My thought is that we will want to include some more validation steps in the future (e.g. #176), and if we group everything under validate it will create room for that work.

[cryptodev-2s]

@cryptodev-2s I haven't had time to review this yet, but I have one initial thought:

Should we rename check-deps to validate? My thought is that we will want to include some more validation steps in the future (e.g. #176), and if we group everything under validate it will create room for that work.

Good point about future validation commands! However, I think check-deps should remain separate from release validation (#176) since:

1. Different scope: check-deps works on any branch (feature branches included), not just release branches
2. Independent use case: Validating dependency changelog entries is useful outside the release process
3. Clear separation: Release-specific validation (Add command for validating release branch #176) deserves its own command

Suggestion:

• Keep: check-deps (or rename to validate-deps for clarity)
• Add: validate-release for Add command for validating release branch #176

Side note: Given we're adding more commands beyond release creation, we could consider renaming the package to something like @metamask/monorepo-tools in a future major version. But that's a separate discussion.

[cryptodev-2s]

@metamaskbot publish-preview

[github-actions]

A preview build for this branch has been published.

You can configure your project to use the preview build with this identifier:

npm:@metamask-previews/[email protected]

See these instructions for more information about preview builds.

[github-actions]

A preview build for this branch has been published.

You can configure your project to use the preview build with this identifier:

npm:@metamask-previews/[email protected]

See these instructions for more information about preview builds.

[mcmire]

check-deps works on any branch (feature branches included), not just release branches

Hmm. Currently this tool is centered around release management, so adding code that doesn't strictly relate to releases feels wrong. I did see your note about renaming this tool to monorepo-tools, but I'm not 100% convinced that's the right direction either. I will have to think about this some more.