Bug: resolves using node_modules when using PnP

[merceyz]

Describe the bug

When running under Yarn PnP enhanced-resolve will still use the node_modules resolution

To Reproduce

Setup:

mkdir repro && cd repro
yarn init -y
yarn set version berry
yarn add enhanced-resolve@5.4.1 lodash@4.17.20

Code:

import { ResolverFactory, CachedInputFileSystem } from 'enhanced-resolve';
import path from 'path';
import fs from 'fs';

const cachedFS = new CachedInputFileSystem(fs);

const commonResolver = ResolverFactory.createResolver({
  fileSystem: cachedFS,
  useSyncFileSystemCalls: true,
});

fs.mkdirSync(path.join(__dirname, 'node_modules/lodash'), { recursive: true });
fs.writeFileSync(path.join(__dirname, 'node_modules/lodash/foo.js'), '');

commonResolver.resolveSync({}, __filename, 'lodash/foo');
throw new Error(`Resolve should have failed since lodash/foo doesn't exist`);

[alexander-akait]

Expected, because modules: ['node_modules'] by default, set modules: []

[merceyz]

I originally did that, but that causes it to throw on resolving commonResolver.resolveSync({}, __filename, 'lodash');

[alexander-akait]

What is the real case problem?

[merceyz]

I'm adding exports support to the PnP api so I need enhanced-resolve to only do the resolution from the result of resolveToUnqualified, when resolveToUnqualified returns a path, if the file enhanced-resolve is looking for doesn't exist it will keep on climbing the filetree and potentially return a path from anything else

[alexander-akait]

Please describe the problem, not code, exports in package.json?

[merceyz]

The problem is that enhanced-resolve walks up the filetree and out of the node_modules folder given to it by PnP

exports in package.json?

Yes, the pnp patch doesn't support it at the moment, it only respects the main field

[alexander-akait]

The problem is that enhanced-resolve walks up the filetree and out of the node_modules folder given to it by PnP

So you expected throw error?

Yes, the pnp patch doesn't support it at the moment, it only respects the main field

It was fixed in the latest version, webpack supports exports for PnP

[merceyz]

So you expected throw error?

Yes, it has been told where the package is but the file (foo.js) is missing so it should throw.

It was fixed in the latest version, webpack supports exports for PnP

I'm aware, it's for the pnpapi itself, so that it's supported when running require and require.resolve in node
yarnpkg/berry#650

[merceyz]

I'm aware this is how the node modules resolution works but would you be open to changing it for when PnP is enabled / adding an option for it? PnP is supposed to not let you resolve something you haven't declared but enhanced-resolve currently allows that to happen, i'm able to workaround this in Yarn so it's not critical but would be nice to avoid all that extra IO only to reject the result

[noahnu]

I've run into this on a project and spent quite a bit of time confused as I wasn't expecting webpack to fallback to node_modules. In my project, this has caused 2 different instances of react-dom to be loaded, one from pnp and one from node_modules, resulting in react crashing.

I'm still trying to figure out why webpack is falling back to node_modules, since I'm not seeing any errors. Would definitely be nice if webpack exclusively used pnp when resolving dependencies in a pnp project.

[jgornick]

@merceyz I'm trying to follow along in this older issue you created, but does #301 help with this original issue?

[merceyz]

No, it shouldn't affect this issue.