[Bug] Yarn plug and play does not work with ESM

Describe the bug

I have tried yarn plug and play with node 13+. When running node --require=./.pnp.cjs index.js there is an error saying Error [ERR_REQUIRE_ESM]: Must use import to load ES Module. Running npm install && node index.js works as expected.

To Reproduce

1. git clone https://github.com/dmail/yarn-pnp.git
2. cd yarn-pnp
3. node --require=./.pnp.cjs index.js

Screenshots

Environment if relevant (please complete the following information):

• OS: MacOS
• Node version: 13.12
• Yarn version: 2.0.0-rc.31

Additional context

Please note how I had to put an empty package.json inside .yarn/releases/ so that .yarn/releases/yarn-berry.js works.

Also your documentation asks to run yarn set version berry but it fails saying Invalid version descriptor "berry".

.

Am I doing something wrong ? Is it expected that plug and play is not yet compatible with node 13+ ?

[paul-soporan]

Tracked in #638.

[DaneTheory]

I think I understand what you’re asking, but please let me know if not. You’d like to enable specific, native features within the context of the active node process at runtime that are not enabled already by default (i.e, passing flags as arguments to node like ‘—experimental-modules’, etc.). To further clarify, you are not asking how to require/run external modules at runtime (i.e. passing ‘—require esm —require dotenv/config’ to ‘node’ so as to not have to manually enable these features by including them first before anything else in your app runs). Is that correct? If it is, fortunately the solution is made very simple particularly with ‘node v13.x’. Provide the runtime features you’d like enabled as a string to the environment variable ‘NODE_OPTIONS’. Run your code using ‘yarn node /path/to/script.js’ as recommended in the docs. When run, you will then see the features enabled. Yes, using Plug’N’Play does result in the contents of ‘node_modules’ from being included within a project in the traditional way they used to; where each module and any dependencies they have are directly downloaded and included as directories within ‘node_modules’ as paths that ‘node’ then is able to resolve natively. But that’s the bi-product of Plug’N’Play, not why it exists. It exists because the traditional way ‘node’ module resolves are handled is not super performant, results in heavily bloated project size, and is limited in any approach by which a developer could share compartmentalized code throughout the scope of a project (i.e. what workspaces are all about). Plug’N’Play abstracts module resolution away from ‘node’ completely, providing as an alternative instead a subset of extendable features via custom fetchers, resolvers, etc. all available with the context provided via ‘Yarn v2’. All that said, the ‘.pnp.js’ file is generated automatically during yarn’s execution lifecycle. It isn’t an actual module, it’s a map which describes how/when/what/where/why all the packages within your project, their dependencies, and their dependencies, all the way down the line need to look like for ‘node’ to then properly resolve and thus making them “requirable”. If you want to include external modules directly to ‘node’ at runtime as project dependencies, not just devDependencies, and have them configured and wired up ready to run at the start of your project initialization, there’s a way to go about doing that as well. Rather than explain it all out here, check out the @yarnPkg repo itself to see how to do this. In short, it’s doable by changing the ‘.yarnrc.yml’ variable ‘yarnPath’ value to a custom path which offers a script file that essentially acts as a go between for yarn to be run from. That’s one way. Another would be to follow the instructions provided in the ‘pnpapi’ docs. This approach ieffects how the final ‘.pnp.js’ file is ultimately generated in a way that seems to be what would be considered “best practice”. Hope this helps. Cheers!