Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yarn pnp should be the first preloaded module in NODE_OPTIONS #6941

Closed
jdalton opened this issue Jan 20, 2019 · 4 comments
Closed

yarn pnp should be the first preloaded module in NODE_OPTIONS #6941

jdalton opened this issue Jan 20, 2019 · 4 comments
Assignees
Labels

Comments

@jdalton
Copy link
Contributor

jdalton commented Jan 20, 2019

The pnp module is currently appended to the existing NODE_OPTIONS value which allows other modules to be attempted to be pre-loaded first and be unresolved.

See source here:

  if (await fs.exists(pnpPath)) {
    nodeOptions += ` --require ${pnpPath}`;
  }

Instead it should be something like:

  if (await fs.exists(pnpPath)) {
    nodeOptions = `--require ${pnpPath} ${nodeOptions}`;
  }

Related to #6629 (comment).

Update:

PR opened at #6942.

@arcanis
Copy link
Member

arcanis commented Jan 20, 2019

Yeah, that's the problem with NODE_OPTIONS - it makes the ordering problematic. For example, there are legitimate situations where you'd want the PnP preload to be made after what's already preloaded.

And the other way around is true as well: if a new --require is added, it'll likely want to be added after the PnP hook, but depending on the order they auto-register it might not be the case.

I can't wait for the Loader API - hopefully it'll force all this to become explicit through configuration rather than a dynamic env parameter. I wonder if a shim could exist until then...

@jdalton
Copy link
Contributor Author

jdalton commented Jan 21, 2019

Yeah, that's the problem with NODE_OPTIONS - it makes the ordering problematic. For example, there are legitimate situations where you'd want the PnP preload to be made after what's already preloaded.

I actually am in that situation, but because pnp is required to resolve --require modules I can't even begin. Before yarn changed to appending to NODE_OPTIONS, from prepending to Node args, my strategy was to first be loaded by pnp, then makes changes I need, then reload pnp. However, now it's nixed at the load step (it's unresolvable without pnp).

Update:

Closed by #6942.

@jdalton jdalton closed this as completed Jan 21, 2019
@arcanis
Copy link
Member

arcanis commented Jan 21, 2019

Why do you need to reload PnP after esm ran? I'm not familiar with how it works, don't you just hook into Module._extensions?

@jdalton
Copy link
Contributor Author

jdalton commented Jan 21, 2019

The esm loader can operate as an isolated package level loader or an application level loader. Unlike babel or other transpilers the esm loader is a runtime simulator and manages the entire load/parse/execution pipeline. We reload pnp through esm so that when pnp modifies its environment its modifying the esm environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants