Linked packages create `pnpm-lock.yaml` conflicts in monorepos

[elliott-with-the-longest-name-on-github]

Affected Packages

I'm not sure 😬 I am not a CI expert -- this is as much a cry for help as it is a bug report!

Problem

I have a monorepo with two packages being managed by pnpm. package-1 and package-2 are linked, and package-2 depends upon package-1.

When package-1 receives a version bump, package-2's version is also bumped. This is what I want. However, because package-2's dependency upon package-1 is also bumped, the lockfile in the root of the monorepo becomes out of date, meaning the release action from merging the changeset PR fails (because pnpm i --frozen-lockfile fails).

Right now, I'm working around this by explicitly running pnpm i --no-frozen-lockfile in my CI, but this is not ideal -- it means I immediately have to open a PR to update the lockfile every time I publish changes through the changeset action.

What's the suggested path here?

Proposed solution

[andrewbranch]

I believe this is also what I’m getting.

1. Version Packages PR
2. Subsequent workflow failure due to lockfile out of date
3. Manual fix to lockfile

It doesn’t seem to me that this problem should be specific to linked packages, though I do have two linked packages, so maybe I’m wrong. But it looks to me like pnpm-lock would have needed an update regardless.

I think this can possibly be solved by changing the version specifier for local package dependencies:

"dependencies": {
- "@other/monorepo-package": "1.2.3",
+ "@other/monorepo-package": "workspace:*"
 }

but it does seem like the PR generation has a bug with pnpm.

[andrewbranch]

Here’s a better way to fix, I think. Haven’t tried it yet but I believe this should work: arethetypeswrong/arethetypeswrong.github.io@2bc5cdd