Adhere to semver rules when using workspace:^ dependencies, fixes #1290

[Pike]

This fixes #1290.

I've adjusted the tests, and also ran my local code against the backstage repository.

On my current version, the main version updates some 200 packages, and with my patch it goes down to some 90.

CC @Rugvip , @freben from that side.

PS: I went for a major release of all affected packages, as this is breaking backwards compat. yarn changeset status gives me:

🦋  info NO packages to be bumped at patch
🦋  ---
🦋  info NO packages to be bumped at minor
🦋  ---
🦋  info Packages to be bumped at major:
🦋  info 
🦋  - @changesets/assemble-release-plan
🦋  - @changesets/cli
🦋  - @changesets/get-release-plan

[changeset-bot]

🦋 Changeset detected

Latest commit: 9b47c69

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@changesets/assemble-release-plan	Major
@changesets/cli	Major
@changesets/get-release-plan	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[Rugvip]

Afaik we'll want to handle ~ in a similar way as well

[Pike]

I started to dabble into the ~ part, and then got stuck in a rabbit hole.

I think the culprit here are pre-releases, which is going to limit the impact this can have for projects like backstage:

> semverSatisfies('1.0.1','~1.0.0')
true
> semverSatisfies('1.0.1-alpha.0','~1.0.0')
false
> semverSatisfies('1.0.1-alpha.0','^1.0.0')
false

This goes back to https://github.com/npm/node-semver?tab=readme-ov-file#prerelease-tags, which reads in backstage lingo: If we bump @backstage/core-plugin-api in a pre-release, we need to also ship a pre-release version of @backstage/plugin-todo, which references that core package with the specific pre-release version.

More details on why that also then affects the non-pre releases is in Emma's comment in #382 (comment).

[ericis]

We ran into an issue where we cannot use yarn changeset publish because it does not respect the monorepo dependencies defined with "workspace:^" in "package.json". We believe this Pull Request would fix that and allow us to use changesets properly. Until then, our only workaround is to manually publish each project, in order, with the command yarn npm publish from each project's directory.

@Andarist and team, is it possible to prioritize this merge?

[adbayb]

Another possible workaround, until Changesets code owners review the pull request, can be to patch (via PNPM if it's your default package manager or the patch-package module) @changesets/assemble-release-plan@6.0.0 dependency with @Pike proposed fix (thanks to him).
Patching is working well confirming the issue fix 🎉 .

I hope this workaround can unblock projects while not rushing @Andarist and the Changesets team 👍 .

[Rugvip]

@adbayb indeed, we'll try it out and see how it works: backstage/backstage#24614. In particular, I expect this to improve our patch release process where we currently see too many package bumps.