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

Tracked in #638.

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!

I don’t understand what you want to know.

To my understanding plug and play exists to avoid creating the whole node_modules immediately. Instead they are dynamically unzipped from an archive. To achieve this yarn override require to unzip a file when it’s required.

Knowing this I think it’s mandatory to execute pnp.js that will override node require mecanism before actually running any other code. Right?