Infra: The release process order of operations may be broken under Yarn 4

[daneah]

Expected behavior The release goes off without a hitch

Actual behavior Errors encountered during the release process

Steps to reproduce the issue

1. Visit the Actions log for the v14.0.0 release
2. Observe the error, having to do with Yarn expecting an immutable install but instead seeing that the @ithaka/pharos version will be updated for @ithaka/pharos-site

Screenshots or code

Run yarn --check-cache --immutable
➤ YN0000: · Yarn 4.1.0
➤ YN0000: ┌ Resolution step
Resolution step
➤ YN0000: └ Completed in 0s 66[8](https://github.com/ithaka/pharos/actions/runs/8194158743/job/22409560036#step:6:9)ms
➤ YN0000: ┌ Post-resolution validation
Post-resolution validation
➤ YN0028: -    "@ithaka/pharos": "npm:^13.3.0"
➤ YN0028: +    "@ithaka/pharos": "npm:^14.0.0"
➤ YN0028: -"@ithaka/pharos@npm:^13.3.0, @ithaka/pharos@workspace:packages/pharos":
➤ YN0028: +"@ithaka/pharos@npm:^14.0.0, @ithaka/pharos@workspace:packages/pharos":
➤ YN0028: The lockfile would have been modified by this install, which is explicitly forbidden.
➤ YN0000: └ Completed
➤ YN0000: · Failed with errors in 0s 833ms
Error: Process completed with exit code 1.

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 running yarn ... --immutable, the installation fails because this change is "pending."

[daneah]

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.

[daneah]

Consider investigating #668 in tandem.

[daneah]

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.

[daneah]

We have released several versions since reporting this, with no further issue during the process.

[brentswisher]

I think the difference between when it happens and when not is when there are releases for pharos-site as as well pharos itself, is that right?

[daneah]

@brentswisher it might be the case, but I had felt like we'd run into that scenario in the past without it causing an issue. Seeing that the release version the site wanted to use in the last failure was a jump of several versions, I'm still unsure of the trigger.

[daneah]

@brentswisher possibly corroborated since the recent release also exhibited this issue, and similarly has Pharos site versioning going on alongside the core package.

[daneah]

NB: This is generally circumvented, for now, by ensuring that yarn.lock is updated with the latest version of @ithaka/pharos, which can be pushed directly to the Version packages pull requests that are automatically opened, or in a separate pull request after merging that one. Merging the yarn.lock updates will without further action allow the publishing to proceed as desired.