fix: failed `publish` command with major dependency changes, tags not created

[miquelbeltran]

Is there an existing issue for this?

• [x] I have searched the existing issues.

Version

6.3.2

Description

Hi all, we use melos in the https://github.com/fluttercommunity/plus_plugins, and I faced some issues today publishing packages.

This is a short description of the problem:

• The package share_plus and share_plus_platform_interface had major updates, to version 11.0.0 and 6.0.0 respectively.
• share_plus: 11.0.0 depends on share_plus_platform_interface: ^6.0.0.
• Run melos publish --no-dry-run --git-tag-version
• share_plus_platform_interface was published.
• but then, the command failed publishing share_plus with the following error:

ERROR: Because share_plus depends on share_plus_platform_interface ^6.0.0 which doesn't match any versions, version solving failed.

This lead to a wrong state in which the git tags were also not published.

Running melos publish --no-dry-run --git-tag-version again I managed to publish share_plus, however all tags are still missing, because the command failed to publish the already published packages.

Steps to reproduce

The release commit: https://github.com/fluttercommunity/plus_plugins/commit/c593c0787c01d600ad591028693e4d711d361b8f

Here you can find the full log attached to see the issue.

plus_plugins_melos_publish_error.txt

You can also review our release process here: https://github.com/fluttercommunity/plus_plugins/blob/main/CONTRIBUTING.md#run-a-release

You can see that when I run git push --tags nothing gets pushed, I checked the tag list and indeed were also not created.

Expected behavior

A couple of things went wrong here:

• share_plus: 11.0.0 could not be published because it didn't find share_plus_platform_interface: 6.0.0, that's probably a fault of pub.dev but that broke the whole publishing process.
• Git tags are not created, probably because there was an error publishing.

If this is an issue that cannot be fixed, I'd like to know what commands I could run to avoid this issue in the future.

Thanks!

Screenshots

No response

Additional context and comments

No response

Other

• [ ] I'm interested in working on a PR for this.

[spydon]

I guess we have to add the option to add --force or --skip-validation and propagate that through to pub publish, since Pub doesn't immediately recognize the new versions when they are published, and even if they did it wouldn't work properly for circular dependencies. Or maybe we should just always run with --force when it is not dry-run, since we have dry-run as the default and expect people to run that first.

Curiously, it looks like it runs with --force if you add --yes currently, so that could be a workaround.

[spydon]

I just realized that most publishing should fail if pub doesn't report back having the version that has just been published, since minor and patch bumps also would register as non-existing, so I wonder if this was a temporary hickup of pub right when you were publishing @miquelbeltran...

[miquelbeltran]

Hi @spydon, I am not sure if this has happened before, but one thing I noticed is that the second time I run the publish command, melos thought all the packages were still not published and attempted to publish them again, like if there was a delay from pub.dev (or it is processing the releasing). Then, of course, pub.dev returned with an error saying that the version exists. Maybe something changed with pub.dev that their endpoints don't immediately report packages as published after upload.

Re: a --force param. That would definitely help in our case!

[github-actions[bot]]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.