Broken lockfile after running turbo prune when using pnpm without `workspace:` dependency prefix

[sjaq]

What version of Turborepo are you using?

1.5.1

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Mac

Describe the Bug

I'm running into issues where pnpm complains about a broken lockfile (using turbo 1.5.1). When trying to create a reproducible case for this issue I've found that explicitly replacing all my in-workspace dependencies with workspace:* instead of * fixes the issue. I'm not really sure if this should be considered a bug, but everything else seems to work just fine without the workspace: protocol.

Given the following workflow:

pnpm turbo prune --scope @app/frontend --docker
cd out/json
cp ../pnpm-*.yaml .
pnpm fetch

I get this error:

Importing packages to virtual store
Already up to date
 WARN  Broken lockfile: no entry for '/@storybook/react/6.5.12_fh43rporo6hpnq24cmgnd4k37i' in pnpm-lock.yaml
 ERR_PNPM_ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY  The lockfile is broken! Resolution step will be performed to fix it.
node_modules/.pnpm                       |  WARN  Cannot find resolution of /@storybook/react/6.5.12_fh43rporo6hpnq24cmgnd4k37i in lockfile

In my case @storbook/react is in fact in the lockfile, but in the original lockfile there's multiple resolutions, but in the pruned lockfile only one seems to be present, creating this error.

Expected Behavior

I expect the generated lockfile in the /out/ folder to allow running pnpm install or pnpm fetch without any problems.

To Reproduce

1. Set up a new turbo project using pnpm.
2. Change the ui dependency version of the apps/web project to * instead of workspace:*.
3. Run pnpm install
4. Run pnpm turbo prune --scope web --docker
5. cd into the out/json directory.
6. Copy over the pruned lockfile cp ../pnpm-*.yaml .
7. Run pnpm fetch

Should output:

Importing packages to virtual store
Already up to date
 WARN  Broken lockfile: no entry for '/ui/0.2.4' in pnpm-lock.yaml
 ERR_PNPM_ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY  The lockfile is broken! Resolution step will be performed to fix it.
node_modules/.pnpm                       |  WARN  Cannot find resolution of /ui/0.2.4 in lockfile

[nathanhammond]

Though it's a bit of a "you're holding it wrong" issue, if the original works for pnpm, we need to make sure that it works in the same manner after prune.

@sjaq thank you for the reduction; that will make this so much simpler to track down.

[chris-olszewski]

Digging into this a bit and it seems pnpm have some different behaviors for resolving "foo": *. If foo exists in the registry it'll install a version from the registry . If it doesn't find a package foo in the registry it will look at the workspace for a package with the same name and link it. This can be seen in the error message where pnpm expected [email protected] to be present.

I'll fix this so we behave in the same way as pnpm, but I wanted to point out that omitting workspace: from the dependency can have unwanted consequences.

[fifi98]

I am getting the same issue with pnpm i, however I do have workspace:* for packages that are in the monorepo:

#22 2.210  ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY  Broken lockfile: no entry for '/react-hook-form/[email protected]' in pnpm-lock.yaml
#22 2.210 
#22 2.210 This issue is probably caused by a badly resolved merge conflict.
#22 2.210 To fix the lockfile, run 'pnpm install --no-frozen-lockfile'.

[chris-olszewski]

Hi, @fifi98. Could you open a new issue with your lockfile and the prune command you ran if possible? I think your issue is unrelated to this since the missing entry is for a registry package.

[fifi98]

Hey @chris-olszewski, sure, I'll open a new issue. My mistake, I thought this was related. Thanks!

[anthonyshew]

Seeing a stale version of turbo here and inactivity. If you're still running into this, please open a new issue with a reproduction using canary.