"ERROR: Attempting to bump to a version that already exists in the registry" with stale semver range

Suddenly our release job gave us this error:

Removing change files:
- @org-foo-5f1fbd45-be6c-49d3-8f97-62b9768cbe26.json
- @org-bar-20d26cbc-3acb-4cbd-b43a-430ae3217888.json
Removing change path
Validating package version - @org/foo@1.0.0 OK!
Validating package version - @org/bar@2.0.0 OK!
Validating package version - @org/random@7.12.25
ERROR: Attempting to bump to a version that already exists in the registry: @org/random@7.12.25
Something went wrong with the publish! Manually update these package and versions:
- @org/foo@1.0.0
- @org/bar@2.0.0
- @org/random@7.12.25
No packages have been published

There were no change files for the offending package, @org/random, or modifications, or anything that would appear to cause beachball to publish it. Its package.json on main was already 7.12.25, so beachball seemed in error to try to publish the package without bumping the version.

I dug deeper and found the cause. It seems to be a bug in beachball, but here is the cause.

@org/random has a dependency on another package. The semver range is this: "@org/epsilon": "^5.4.0",. But @org/epsilon's current version is 5.4.1. Believe it or not, this is the cause of the bug. I debugged the execution: publish() -> gatherBumpInfo() -> bumpInPlace() -> setDependentVersions().

This outdated semver range (^5.4.0) was introduced by a developer in an MR. On main, beachball updates the semver ranges, so all our other packages have ^5.4.1, but this developer had pasted ^5.4.0 at a time when main had ^5.4.0. I worry that this will happen again. There were no warning signs when his MR built and passed, and merged and even released a package. But the next release to come along was the one that surfaced the error, with a strange error.

Anyway, we're on beachball 2.3.0, so let me try the latest... yep, happens with 2.16.0 too.

So the workaround is to update our semver ranges, but this remains a footgun because there's no good way to prevent a developer from committing an outdated range, besides having the eyes of an eagle. Anyway, I'm excited to see the progress you guys have made so far. Thanks.

Start with the publish() flow described in the report: gatherBumpInfo(), bumpInPlace(), and setDependentVersions(). Reproduce the stale @org/epsilon range case and inspect how @org/random is selected for a bump despite having no change files. Done means the behavior is covered by a regression test and the release job no longer attempts to publish an unchanged existing version.