Bug report

What is the current behavior?

When using a loader from a scoped package (@<scope>/<package>) through pnpm, the system will resolve the correct path, but then fail to find the module for usage as a loader:

Error: Cannot find module '<root>/node_modules/.pnpm/@next#react-refresh-utils@10.2.0_377debd9c60f944826ee39c3e9eaa238/node_modules/@next/react-refresh-utils/loader.js'
Require stack:
- <root>/node_modules/.pnpm/loader-runner@4.2.0/node_modules/loader-runner/lib/loadLoader.js
- <root>/node_modules/.pnpm/loader-runner@4.2.0/node_modules/loader-runner/lib/LoaderRunner.js

If the current behavior is a bug, please provide the steps to reproduce.

Download these files into an empty directory:

package.json and webpack.config.js: https://gist.github.com/Kiskae/966f4a24e61cc6acc99b0155dea125cd

Run the following commands within that directory:

# enable default webpack behavior
touch src.js
# install node_modules through pnpm
npx pnpm@6.3.0 install
npx pnpm@6.3.0 run w

This should then produce a build error even though the source file is empty, since it cannot find the loader even though it resolved the path successfully.

What is the expected behavior?

Given that the loader is correctly resolved to a regular file on the filesystem, the loader loader should be able to find and execute it. The reason why it only affects scoped loaders is because of a change made in pnpm 6.0.0:

The layout of the virtual store directory has changed (node_modules/.pnpm) to allow keeping cache in it: All packages inside the virtual store directory are on the same depth. Instead of subdirectories, one directory is used with # instead of slashes.

This appears to then trigger an issue similar to #12156 since the package directory is remapped to @<scope>#<package>.

Other relevant information: webpack version: webpack 5.36.2 Node.js version: v14.16.0 Operating System: Linux 5.11.0-7614-generic #15~1618626693~20.10~ecb25cd-Ubuntu SMP x86_64 GNU/Linux Additional tools: pnpm 6.3.0