[Bug?]: prefersUnplugged should take precedence over pkg.conditions

[jonaskuske]

Self-service

• [X] I'd be willing to implement a fix

Describe the bug

In this comment, esbuild was recommended to add prefersUnplugged: false to its optional platform-specific deps so they don't get extracted: https://github.com/yarnpkg/berry/issues/3317#issuecomment-925410441. And indeed, all esbuild variants include the preferUnplugged key: https://unpkg.com/browse/[email protected]/package.json

Unfortunately the prefersUnplugged key is ignored and all of the optional deps are extracted anyway, because the pkg.conditions !== null check takes precedence over preferUnplugged: https://github.com/yarnpkg/berry/blob/cf67f3a15052cf809cefcc0df58937874ad3c34d/packages/plugin-pnp/sources/PnpLinker.ts#L434-L438

These checks should be in reverse order. By reversing the two checks, everything works: esbuild is unplugged but its optional dependencies are not. When running esbuild, it copies the correct platform-specific binary into its writable, unplugged dir and executes it.

And if you change the location where esbuild stores the platform-specific binary (as I proposed in this PR: https://github.com/evanw/esbuild/pull/2457), it even works with enableScripts: false and nothing unplugged.

To reproduce

mkdir repro && cd $_
yarn init -2 -y
yarn add esbuild
# should be empty but prints opt dep:
ls .yarn/unplugged | grep -P 'esbuild-(?!(npm))'

Environment

System:
    OS: Linux 5.10 Ubuntu 20.04.4 LTS (Focal Fossa)
    CPU: (8) x64 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
  Binaries:
    Node: 16.14.2 - /tmp/xfs-96532741/node
    Yarn: 3.2.2 - /tmp/xfs-96532741/yarn
    npm: 8.5.0 - /mnt/wslg/runtime-dir/fnm_multishells/15691_1660563665547/bin/npm

Additional context

No response

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

[evanw]

FYI esbuild now uses prefersUnplugged: true as of version 0.15.15. Your documentation recommends extracting to node_modules/.cache but your users don't like that as it causes the node_modules directory to be created when it otherwise isn't needed. So to avoid needing to create node_modules/.cache, all of esbuild's platform-specific packages now request to be unplugged.

[jonaskuske]

Yep, followed those developments! Creating node_modules just for .cache, .vite etc is annoying indeed, should've probably been somewhere in .yarn/tmp or so, not to annoy users. Anyway, guess I'll have to live with unplugged esbuild packages :) Checking in .yarn/unplugged is annoying, but guess the whole 0-installs idea is dying anyway with native deps like esbuild or swc becoming more and more common. Yarn 4 stopped defaulting to 0-installs too I think.