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

[matthias-ccri]

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/[email protected] OK!
Validating package version - @org/[email protected] OK!
Validating package version - @org/[email protected]
ERROR: Attempting to bump to a version that already exists in the registry: @org/[email protected]
Something went wrong with the publish! Manually update these package and versions:
- @org/[email protected]
- @org/[email protected]
- @org/[email protected]
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.

[alloy]

Had the same issue; thanks for the workaround @matthias-ccri :pray:

https://github.com/microsoft/graphitation/commit/e8db05bf2133c9bb687aae8de58141f2552d5dda

[ecraig12345]

In Fluent UI we use syncpack to help prevent this type of issue (though obviously having beachball handle it better would be good). Here's our syncpack config for reference if it's helpful.

[alloy]

Thanks for sharing, @ecraig12345. That's a lot of config, I'll wait and see how often this ends up happening for us before trying to understand syncpack 😅