lib: always initialize esm loader callbackMap

[codebytere]

Refs #34060.

We should instead unilaterally initialize the callbackMap and return early if an embedder is choosing to not use the Node.js esm loader is in an embedder context.

I also updated the corresponding tests to more directly check importModuleDynamically functionality affected by a decision to not use the esm loader provided by Node.js.

cc @addaleax@joyeecheung

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/32158/

[addaleax]

Would it maybe make more sense to provide callbackMap unconditionally? e.g. this (untested):

diff --git a/lib/internal/bootstrap/pre_execution.js b/lib/internal/bootstrap/pre_execution.js index a51dbf05ec4f..8d4c44922ac0 100644 --- a/lib/internal/bootstrap/pre_execution.js+++ b/lib/internal/bootstrap/pre_execution.js@@ -60,9 +60,7 @@ function prepareMainThreadExecution(expandArgv1 = false){initializeWASI(); initializeCJSLoader(); - if (!shouldNotRegisterESMLoader){- initializeESMLoader();- }+ initializeESMLoader(); const CJSLoader = require('internal/modules/cjs/loader'); assert(!CJSLoader.hasLoadedAnyUserCJSModule); @@ -406,6 +404,8 @@ function initializeESMLoader(){// Create this WeakMap in js-land because V8 has no C++ API for WeakMap. internalBinding('module_wrap').callbackMap = new SafeWeakMap(); + if (!shouldNotRegisterESMLoader) return;+ const{setImportModuleDynamicallyCallback, setInitializeImportMetaObjectCallback

That requires a smaller patch and would also make things easier in case we do figure out a good way to mix ESM loaders (e.g. by making them per-Context)?

[codebytere]

That also works! Will do :)

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/32207/

[codebytere]

Landed in 37fc587