enhanced-resolve: What is the expected fallback behavior when restrictions is combined with multiple modules entries?

[bregenspan]

I have a project with this resolver configuration:

modules: ['node_modules', '/build/node_modules'],
restrictions: new RegExp('^/build/node_modules')

The intent is to enforce a "jail" where modules will only ever be resolved from /build/node_modules. Because the project has a non-flat node_modules, I kept node_modules in resolve.modules to allow a package like /build/node_modules/foo to resolve its own relative ./node_modules/bar. restrictions is intended to block upward traversal for node_modules, ensuring that resolved modules are contained in /build/node_modules.

This seems to work as expected except in the case where an import resolves to a package that has an exports field defined. In that case, an error is thrown after the initial relative node_modules lookup (first entry in modules array), and no fallback happens to the second entry in the modules array.

Desired Behavior

If we have the modules/restrictions configuration above and the folder structure:

• /node_modules/foo
• /build/node_modules/foo

And are resolving for an /entry.js containing import 'foo':

1. Relative node_modules lookup happens first: /node_modules/foo is found but doesn't meet restrictions. (Resolution will then traverse upwards but find nothing else that matches restrictions).
2. Fallback to second modules entry: resolver tries /build/node_modules and successfully resolves /build/node_modules/foo.

Actual Behavior

• When /node_modules/foo/package.json has no exports field defined, actual behavior matches Desired Behavior above.
• But when /node_modules/foo/package.json does have an exports field, fallback to the second modules entry (/build/node_modules) fails, because an error is thrown:
  • Package path . is exported from package '/node_modules/foo' but no valid target file was found (see exports field in '/node_modules/foo/package.json')

(Sorry for a very wordy question, but this is a complicated scenario to describe! I'm wondering if this looks like a bug, in which case I'll file it as such. It's hard to know from context of issues like #9165, since they didn't explicitly contemplate this modules fallback case)

[alexander-akait]

Hm, looks like due webpack/enhanced-resolve#399, but sounds like a small bug, can you try locally - webpack/enhanced-resolve#600?

[bregenspan]

Wow that was fast, thank you! I tried it against a test case I (well, mostly Claude Code) had written before this and it fixes, and it also works as expected in a minimal repro build setup that was failing before. (Can't easily push that up from my work computer, but it's very close to the fixture setup in webpack/enhanced-resolve#600)

[alexander-akait]

Great, I'll release it and you can update the transitive dependency (enhanced-resolve) and test it on a real project, will make soon

[alexander-akait]

Done - https://github.com/webpack/enhanced-resolve/releases/tag/v5.22.2

[bregenspan]

Nice, thanks again @alexander-akait! For my actual project, the issue repros under 5.22.0, no longer repros under 5.22.2. 👍