esm: globals should be wrapped to stay in sync with ESM

[bmeck]

This fixes the behavior of the builtin module proxy for process so that test/parallel/test-global-setters.js works even when ESM is turned on via --experimental-modules by changing the global to use the Proxy form that ESM creates for named export syncing.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[bmeck]

test/parallel/test-bootstrap-modules.js is still failing and we can add NativeModule process if thats ok @joyeecheung

test/parallel/test-bootstrap-modules.js adds a getter that errors to process and the sync operation of the ESM proxy errors out on that overly eagerly, should resolve to a path forward on how to handle that test @nodejs/modules

[joyeecheung]

If this is done when ESM is not even used doesn't this just slow down access to globalThis.process unconditionally?

[bmeck]

Yup, but that's how to keep ESM names synced

[mcollina]

I’m provisionally -1 as it’ll slow down access to process and it sits in a lot of hot paths (because of process.nextTick).

This needs a benchmark run on nextTick and stream at a minimum.

[bmeck]

@mcollina the way that --experimental-modules added named exports wraps all builtin modules in Proxies, I agree there will be slowdown but the request of having named exports would still require proxies around things even outside this PR and already does so. For now the PR still is gated by the --experimental-modules flag. I think discussions on performance impact of unflagging --experimental-modules extends far outside this PR. This PR is just a bugfix essentially if --experimental-modules were to be unflagged.

[mcollina]

An alternative option is not to expose static export for the process object and module, as the issue is very specific for process.

There is correlation between process.nextTick performance and Node.js baseline throughput in both http and file processing, because it's so heavily used within the whole of Node.js core. We cannot simply const { nextTick } = process because we have to support https://github.com/sinonjs/lolex and similar. As a result, making process being a proxy is not feasible. The process.nextTick case is unique in this sense, however we might have to look at EventEmitter and Streams as well.

My overall assumption about ESM is that it should not slow down normal execution, while it could slow down application startup. This PR is going to affect execution.

[MylesBorins]

Could we internally us a non proxy instance (maybe via internal reference)?

[guybedford]

Shall we close this PR?

[bmeck]

closed in favor of #29737