Open daneah opened 4 months ago
One possible fix entails running yarn install
(without --immutable
) after running yarn release
, as part of the steps in the release workflow, and pushing the result to the branch that's created. This will ensure that what gets merged into main
from the pull request already has the "undesired" changes that happen when actually trying to generate the release. It also makes sure that @ithaka/pharos-site
is always using the latest release of @ithaka/pharos
.
We recently ran into issues with that, too, though, because the site hadn't been updated to accommodate breaking major changes. So a different solution would be to make sure the workspaces aren't actually coupled, such that @ithaka/pharos-site
can statically reference some version of @ithaka/pharos
and doesn't get updated at all as part of this flow. This is the "safest," but also means we could be inclined to get outdated.
Consider investigating #668 in tandem.
This issue did not occur in a recent release—will need to better understand what triggers Yarn to update the workspace dependencies during this flow.
Expected behavior The release goes off without a hitch
Actual behavior Errors encountered during the release process
Steps to reproduce the issue
@ithaka/pharos
version will be updated for@ithaka/pharos-site
Screenshots or code
Additional information
This may be due to how Yarn 4 handles workspace dependencies, as this release was the first one done using Yarn 4 instead of Yarn 1. Because the release process includes bumping the version of the
@ithaka/pharos
package, and because the@ithaka/pharos-site
package depends on it as a workspace, Yarn wants to bump it as well, and because this all happens prior to runningyarn ... --immutable
, the installation fails because this change is "pending."