Enable PnP by default if within a PnP environment?
See original GitHub issueThis 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)?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:16 (14 by maintainers)
Top GitHub Comments
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.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 overridingchild_process
andworker_threads
).