lib: expose a global node proxy in eval script and REPL

[aduh95]

This global is meant to be a convenient shortcut to access core modules.

• figure out REPL autocompletion for the proxy.
• fix Unexpected global(s) found: node test failures.

[devsnek]

what's the reasoning for this? all the core modules are already available as globals in the repl

[aduh95]

what's the reasoning for this? all the core modules are already available as globals in the repl

The idea would be to deprecate that. The problem with having Node.js specific globals is that it clashes with other globals (e.g. crypto references the Web Crypto API in other JS runtimes).

[tniessen]

I haven't given this much thought yet, but I don't know if I am a fan of adding another global as the solution to "we added globals that are now a problem."

[Slayer95]

The issue with crypto should be studied from the lens of scripts and libraries maintainers.

Currently, code that is to be consumed by both client and server must feature-test the content of the crypto global to know what it is about.

After several Node.js major versions are released, the old versions will keep being used in the wild, and so library maintainers will still need to feature-test the crypto global to figure out how to work with or without it.

So on one hand the end-user benefits are non-existent. And on the other hand, the deprecation of fs, path and other globals in the REPL will noticeably reduce its usability for quick scripts.

[antsmartian]

@aduh95 ping. Are we planning to work on this to get it to a closure?

[aduh95]

Not really. The idea implemented in this PR was to solve the clash for crypto name in REPL and node --eval context between node:crypto and globalThis.crypto, but we went another way and I haven't seen any report complaining with the way it's implemented.
Closing this as I'm not working on it, but I'm curious to hear if you have thoughts on whether we should reconsider it and why.