Adding a dep to a package in a pnpmfile and then removing that dep, doesn't remove the dep when running pnpm update --depth=99 --filter .

[vjpr]

It also didn't work when running pnpm update in the workspace package dir, and neither running pnpm i in the monorepo root.

I had to manually remove the entries from the lockfile.

Quick repro:

1. Add a dep
2. Then use pnpmfile to add a dep to a dep
3. Then run pnpm update --filter .
4. Then remove the pnpmfile stuff.
5. Then run pnpm update --filter .
6. Run pnpm why <dep>
7. It's still there.

NOTE: I am using hoist = false in .npmrc.

pnpm version: 6.14.3

Code to reproduce the issue:

https://github.com/vjpr/issue-pnpm-update-and-pnpmfile-3735

Additional information:

• node -v prints: 16
• Windows, macOS, or Linux?: macOS

[vjpr]

Added a full repro here with steps to follow and printed output:

https://github.com/vjpr/issue-pnpm-update-and-pnpmfile-3735

Basically, if you use pnpmfile to add a dep to a package, but then decide to remove it, its stuck in the lockfile forever, and you have to manually remove it.

And any other package that uses the same dep will have the same problem.

Makes for very unpredictable behaviour.

It also happens with packageExtensions.

[guillaumep]

This happens with a simpler scenario as well:

• Add a dependency in package.json in pnpm.packageExtensions
• Run pnpm install. The dependency is added for that package in pnpm-lock.yaml.
• Remove the dependency from pnpm.packageExtensions.
• Run pnpm install. The previously added dependency stays in pnpm-lock.yaml.

Expected: the previously added dependency should be removed from pnpm-lock.yaml.

This is a bit annoying -- however thanks for pnpm, it's great!

@vjpr Might I suggest renaming the bug title to show that the bug happens not only when using pnpm update?