`turbo prune` leaves orphaned lockfile entries from `yarn`'s built-in packageExtensions (plugin-compat)

[kaisermann]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Tested with turbo@2.8.3-canary.14. Issue still reproduces.

Link to code that reproduces this issue

https://github.com/kaisermann/turbo-prune-yarn-packageextensions-repro

Which canary version will you have in your reproduction?

2.8.3-canary.14

Environment information

CLI:
   Version: 2.8.3-canary.14
   Daemon status: Not running
   Package manager: berry

Platform:
   Architecture: aarch64
   Operating system: macos

Environment:
   CI: None

Expected behavior

After running turbo prune <workspace>, the pruned yarn.lock should only contain entries needed by the pruned workspace graph. Running yarn install --immutable in the pruned output directory should succeed.

Actual behavior

turbo prune leaves orphaned lockfile entries in the pruned yarn.lock that were injected by Yarn's built-in packageExtensions (the plugin-compat database in yarnpkg-extensions).

These entries are not real npm dependencies; they are transparently added by Yarn during resolution for packages that have known missing type dependencies. They appear in the lockfile as normal dependency entries.

When turbo prune removes a workspace (and its transitive dependencies) that triggered these extensions, it correctly strips the triggering package (e.g., got@9.6.0) but fails to strip the extension-injected dependencies (e.g., @types/keyv@3.1.4, @types/responselike@1.0.3), leaving them orphaned in the pruned lockfile.

This causes yarn install --immutable to fail with:

➤ YN0085: │ - @types/keyv@npm:3.1.4, @types/responselike@npm:1.0.3
➤ YN0028: │ -"@types/keyv@npm:^3.1.1":
➤ YN0028: │ -  version: 3.1.4
...
➤ YN0028: │ -"@types/responselike@npm:^1.0.0":
➤ YN0028: │ -  version: 1.0.3
...
➤ YN0028: │ The lockfile would have been modified by this install, which is explicitly forbidden.

This is Yarn-only. npm and pnpm are not affected because they do not have a built-in packageExtensions database.

To Reproduce

git clone https://github.com/kaisermann/turbo-prune-yarn-packageextensions-repro
cd turbo-prune-yarn-packageextensions-repro
yarn install
yarn turbo prune app-a --out-dir=out
cd out
yarn install --immutable   # FAILS with YN0028

The repro was created from npx create-turbo@canary -e with-shell-commands with these minimal changes:

1. Upgraded from Yarn 1 to Yarn 4.5.0 (packageManager + .yarnrc.yml with nodeLinker: node-modules)
2. Added got@^9.6.0 as a dependency of app-b (triggers Yarn's built-in packageExtensions to inject @types/keyv and @types/responselike)

[lodmfjord]

Has this been fixed?

[BertVanHecke]

Is this fixed? We are on version 2.8.17 and still get this error.

[anthonyshew]

Have you tried turbo@canary? If you still see the issue there, please open an Issue with a reproduction.

[BertVanHecke]

No it does not work with turbo@canary.

[anthonyshew]

If you still see the issue there, please open an Issue with a reproduction.