Kristoffer K.

I would prefer if the `FIXME` was fixed before this is merged but as I said in https://github.com/webpack/enhanced-resolve/pull/301#discussion_r701406073 i'm not sure how and was hoping either of you did

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

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...

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...

> 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...

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...

That's an implementation detail and can change so it's not enough to just peer depend on `vue` and assume you have access to `@vue/reactivity`. It's relying on hoisting to make...

Yeah, that's a valid interpretation but it also needs to declare `@vue/reactivity`

> yarn is responsible for resolving foo/bar to /path/to/pnp/virtual/foo.zip or /monorepo/packages/foo. resolveToUnqualified does that. In this case it would resolve to `/path/to/pnp/virtual/foo.zip/bar` https://yarnpkg.com/advanced/pnpapi/#resolvetounqualified

Indeed, that's why the reproduction uses the `node-modules` linker (`node_modules` folder)