Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Failure to load loader from a scoped package when using pnpm

See original GitHub issue

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

Issue Analytics

State:
Created 2 years ago
Comments:15 (11 by maintainers)

Top GitHub Comments

1reaction

snitin315commented, Jun 19, 2021

@sidverma32 Yes, feel free to send a PR.

0reactions

alexander-akaitcommented, May 10, 2022

Let’s close as fixed, if somebody will faced with bug again, feel free to open an issue

Top Results From Across the Web

Problems with pnpm and the way loaders are resolved #5087

We have issues in lots of applications because webpack can't resolve packages in the node_modules created by pnpm. I think it is because...

Package is not publishing to npm (not in the npm registry)

GitHub Packages only supports scoped npm packages. Scoped packages have names with the format of @owner/name. Scoped packages always begin ...

package.json | pnpm

During local development, pnpm will always fail with an error message if its version does not match the one specified in the engines...

less-loader | webpack - JS.ORG

Disclaimer: less-loader is a third-party package maintained by community ... test: /\.less$/i, use: [ // compiles Less to CSS "style-loader", "css-loader", ...

Configuration options | Yarn - Package Manager

yarnrc won't do). Environment variables can be accessed from setting definitions by using the ${NAME} syntax when defining the values. By default Yarn...