fix(version-bump-check): stop requiring a bump for package-lock.json changes

[mairas]

version-bump-check.yml excludes lockfiles from the package-affecting files with \.(lock)$, which matches yarn.lock and Cargo.lock but not package-lock.json. A PR that only changes an npm lockfile therefore demands a VERSION bump when VERSION equals the latest stable release. The workspace rule already says lockfiles do not count.

This came up committing lockfiles to signalk-duckdb-history-provider and signalk-questdb-history-provider (whose VERSION equals its latest stable release). The exclusion now also matches package-lock.json at any depth.

tests/version-bump-check.test.sh runs the step against a throwaway repository with a stubbed gh: package-lock.json, yarn.lock and Cargo.lock alone pass, and a source change fails without a bump and passes with one. The package-lock.json case failed before the change.

Callers on @main get this on merge; it only removes a false failure.

---

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

Next included review available in 15 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 573b2e44-a7b4-457a-915f-38cc2efe60be

📥 Commits

Reviewing files that changed from the base of the PR and between 95d10b7 and 8f09fdd.

📒 Files selected for processing (2)

• .github/workflows/version-bump-check.yml
• tests/version-bump-check.test.sh

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[mairas]

Code Review Results

Scope: version-bump-check.yml lockfile exclusion and tests/version-bump-check.test.sh (96-line diff). CodeRabbit was rate-limited.
Reviewers: correctness, testing, maintainability, project-standards

P3 -- Low

#	File	Issue	Reviewer	Confidence	Route
1	tests/version-bump-check.test.sh	Only a root-level package-lock.json is tested; the nested branch of the regex and near-miss names are not.	testing, maintainability, correctness, project-standards	0.85	safe_auto -> review-fixer
2	version-bump-check.yml	In cockpit-apt, cockpit-authelia-users and cockpit-container-apps, debian/rules builds the frontend from frontend/package-lock.json, so a lockfile-only PR changes bundled code in the .deb without opening a release cycle. The same already holds for Cargo.lock and uv.lock; this PR extends an existing policy.	correctness	0.65	advisory -> human

Pre-existing Issues (action required)

#	File	Issue	Reviewer	Action
1	version-bump-check.yml	App metadata check, git tag fallback and no-stable-tag skip are untested.	testing	file-issue

Coverage

• Residual: npm-shrinkwrap.json and pnpm-lock.yaml still count as package-affecting; no caller uses them, and npm publishes npm-shrinkwrap.json inside the package, so counting it is arguably right.
• Callers pinned to @v1 later get this only after a release moves the tag.

---

Verdict: Ready with fixes (finding 2 is a policy question for a human)

[mairas]

Amended (now 8f09fdd): the test adds frontend/package-lock.json (passes without a bump) and mypackage-lock.json and package-lock.jsonc (still need a bump); 8 checks pass. Finding 2 is left for a decision on whether lockfiles should count for repositories that build bundled code into the .deb. The pre-existing test gaps are .

[mairas]

Decision on finding 2: keep the rule. Lockfiles never force a VERSION bump; a dependency-only change still produces a new +N package. The check exists to catch forgotten bumps for code changes, not to decide semver for dependency updates, and this matches how Cargo.lock and uv.lock are already treated.