[Bug?]: `yarn dlx` breaks with hardlinked node modules

Self-service

• I’d be willing to implement a fix

Describe the bug

yarn dlx breaks when nmMode is set to hardlinks-[local/global]

To reproduce

await yarn('init', '-y');
await yarn('config', 'set', 'enableGlobalCache', 'true');
await yarn('config', 'set', 'nodeLinker', 'node-modules');
await yarn('config', 'set', 'nmMode', 'hardlinks-global');

await expect(yarn('dlx', 'sirv-cli', '-v')).rejects.not.toThrow();

Environment

System: OS: Linux 5.12 Arch Linux CPU: (4) x64 Intel® Core™ i3-5005U CPU @ 2.00GHz Binaries: Node: 16.5.0 - /tmp/xfs-c1cde8a3/node Yarn: 3.0.0 - /tmp/xfs-c1cde8a3/yarn npm: 7.20.0 - ~/.local/npm-global/bin/npm

Additional context

[merceyz]

If we can’t make sure they are, maybe we should not use hardlinks for dlx, then? How do we detect that we are linking under dlx in the latter case?

We can set dlx specific settings like I did in https://github.com/yarnpkg/berry/pull/2677 but we should probably not make that the solution in this case since any project can be on a different device than the cache, perhaps we could gracefully downgrade to hardlinks-local

[merceyz]

Why not force nmMode: classic for dlx?

Since it would only fix yarn dlx and wouldn’t help for cases like https://github.com/yarnpkg/berry/issues/3191

I can add smart code to dlx, to detect whether it is possible to create hardlinks between the three and depending on the result either use hardlinkks-global, hardlinks-local or classic, but it seems too complex for the little gain. Its much easier to just force nmMode:: classic if nm linker is used for dlx, what do you think?

I write this after looking at https://github.com/yarnpkg/berry/pull/3204 but I think just making the linker fallback to hardlinks-local in general is good enough, it’s unlikely that different parts of the node_modules folder is on different devices