Enable PnP by default if within a PnP environment?

This is a followup to #174. In this PR, we’ve implemented normalize-options.js as a way for third-party runtimes to hook into resolve by default and modify its default options.

It worked really well, and unlocked many packages - Babel being an important one. I just found out, however, that it doesn’t work with one particular project: Next.js. For some reason, Next precompiles resolve and thus causes normalize-options.js to disappear, leaving no chance to the hook to override it.

There are a few options to solve that on their side, but I wonder: could/should resolve improve its support? Since 2018 a lot of new projects have adopted PnP, including enhanced-resolve from Webpack. Coupled to the fact that:

• This behaviour is in essence already enabled by default for everyone using PnP
• It doesn’t affect at all people that don’t use PnP
• The PnP API has been very stable for a while now
• PnP will be the default in Yarn 2+

How would you feel about adding the PnP logic into resolve itself if process.versions.pnp is detected (we would still have forceNodeResolution to prevent it, just like it is at the moment)?

[arcanis]

I made a tentative PR: https://github.com/browserify/resolve/pull/205 - basically giving the hook the option to skip the path.join if it doesn’t apply to a package.

If possible at all, I would really appreciate if the change could be made in a semver-minor release. Lots of packages are depending on resolve, and that would help compatibility in one fell swoop.

[arcanis]

I’m a bit cautious doing this, as it’s generally quite intrusive and prone to break 🤔

I feel like the less we need to add a layer between Node and its users, the better I feel (for example that’s part of the reason why we use NODE_OPTIONS to inject the runtime instead of overriding child_process and worker_threads).