fix(pnp): always initialize the ESM loader when enabled

[merceyz]

What's the problem this PR addresses?

Dynamic imports doesn't work in commonjs files when the entrypoint is also a commonjs module.

Fixes #3671
Fixes #3687
Fixes PnP support in the Babel repo (cc @nicolo-ribaudo)
Fixes (part of) the failing Angular e2e test

How did you fix it?

• Update the ESM loader to handle extensionless files (workaround for node --loader treats entrypoint as ESM when should be loaded as CJS nodejs/node#33226), this allows removing the patch to require('module').runMain. Removing that patch lets Node initialize the loader regardless of the module type
• Update process.mainModule when the commonjs module is already in the cache when loading the main module

Checklist

• I have read the Contributing Guide.
• I have set the packages that need to be released for my changes to be effective.
• I will check that all automated PR checks pass before the PR gets reviewed.

[arcanis]

Quick note: it's worth adding a (in-PR) comment when tests are removed, explaining why they aren't relevant anymore (were they bugged?) 😃

[merceyz]

I documented it in the commit that removed them

[timmywil]

Could this be released to canary?

[merceyz]

Sure, running it now https://github.com/yarnpkg/berry/actions/runs/1468300994

Alternatively you can get it from sources

yarn set version from sources

[teohhanhui]

Looks like that has failed: https://github.com/yarnpkg/berry/runs/4229011500?check_suite_focus=true#step:7:1257

[merceyz]

The publish to the registry failed but set version... doesn't use the registry so it doesn't matter.

yarn set version canary

[kherock]

The extensionless file workaround for nodejs/node#33226 in this PR doesn't work when I'm attempting to load an entrypoint with an arbitrary file extension that's intended to be parsed by a require hook like babel-register. I have a local package that loads an entrypoint with a .ts extension that should normally load as CJS.

Are there any gotchas to renaming the ``: and `.js`: cases to the default: case? I expect .ts to load as CJS when the package doesn't declare "type": "module". This assumption might change once .mts exists, but for now defaulting to the package type feels like the most correct behavior.

[merceyz]

Could you open a seperate issue to track that?

Are there any gotchas to renaming the ``: and .js: cases to the default: case?

We don't want to deviate from how Node behaves more than we have to so we could only do that for the entrypoint

[tavoyne]

I'm experiencing an analogous issue that this PR doesn't seem to be fixing.

I'm trying to use the @mdx-js/loader@2.0.0-rc.2 webpack loader. In the package's entry point (it's a .cjs file), there's a dynamic import of an ES module that causes the following error:

node:internal/errors:464
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/blackjelly/code/blog-3/.yarn/__virtual__/@mdx-js-loader-virtual-a537165eb1/0/cache/@mdx-js-loader-npm-2.0.0-rc.2-eb4487e27d-5637b8d92c.zip/node_modules/@mdx-js/loader/lib/index.js' imported from /Users/blackjelly/code/blog-3/.yarn/__virtual__/@mdx-js-loader-virtual-a537165eb1/0/cache/@mdx-js-loader-npm-2.0.0-rc.2-eb4487e27d-5637b8d92c.zip/node_modules/@mdx-js/loader/index.cjs

Which setting Yarn's version from sources or using canary doesn't fix.

[merceyz]

Please open a bug report with a reproduction