Yarn 2/3 devPruning step fetches all dependencies again.

[anthonyProductPlan]

Describe the bug
When doing the devPruning step on a project with a .yarn/cache checked in with the repo (zero install) the devPruning step wastes time fetching everything since it says it cannot find them in the cache. Skipping the pruning ends up with a larger slug, so you are stuck picking between a large slug or a pointless zero-install setup.

-----> Pruning devDependencies
Running 'yarn heroku prune'
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 0s 207ms
➤ YN0000: ┌ Fetch step
➤ YN0013: │ @bull-board/api@npm:4.11.0 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ @bull-board/express@npm:4.11.0 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ @bull-board/ui@npm:4.11.0 can't be found in the cache and will be fetched from the remote registry
...
➤ YN0000: └ Completed in 39s 758ms

To Reproduce
Steps to reproduce the behavior:

1. Trigger a build on a project with Yarn 3 and unset the YARN2_SKIP_PRUNING flag.

Versions (please complete the following information):

• Heroku Stack: Heroku-22
• Node Version: 16.19.0
• NPM or Yarn Version: 3.3.1
• Buildpack Version: latest

Additional context
Add any other context about the problem here.

[vanderhoop]

I'm seeing the same behavior as above. The initial installation step registers the yarn cache and foregoes fetching any remote dependencies, but after building, the 'pruning devDependencies' step moves forward.. and results in remote fetches of my dependencies, adding ~30s to my build times, despite the vast majority of them being available in the cache...

My solution for the moment is to set YARN2_SKIP_PRUNING=true in my build env, as the time savings are worth the current slug bloat, but I'd ideally users would be able to prune dev dependencies to keep their slug sizes as small as possible without incurring non-trivial time penalties.

buildpack: v211
node: 16.16.0
npm: 8.11.0
yarn: 3.2.3

Note: I'm building on gigalixir-20 stack, so it's possible a stack discrepancy caused my issue, but I'm seeing behavior that's nearly identical to the behavior described by @anthonyProductPlan, so 🤷🏻‍♂️