Node.js built-in module support in the vm context

[legendecas]

Scripts/Modules running in the context created with vm.createContext can not access various Node.js built-in apis/modules like URL, node:assert, node:http, etc. This makes it cumbersome to create a disposable context for use cases like hot-module-reload to run existing node.js apps.

We can provide a built-in API to create a context (or a new NodeRealm for compatibility) with full-fledged Node.js built-in modules support. It allows object exchanges between realms and shares the same loop with the main context.
, similar to the existing vm.context.

/cc @mcollina @nodejs/realm @nodejs/vm

[cjihrig]

Thanks for opening this @legendecas. Do you have any plan or idea for next steps towards a NodeRealm?

[legendecas]

I'm experimenting with a local setup to expose Web globals like URL in ShadowRealm (based on #46556). I believe many infrastructures can be shared between ShadowRealm and the NodeRealm. The following steps for NodeRealm can be:

• Defines the APIs to create a VM context with Node.js built-ins.
  • CommonJS (e.g. createRequire from the outer realm).
  • ES Modules (e.g. import from the outer realm).
  • Synthetic modules (vm.Script and vm.Module)
• Defines the APIs to be exposed in the NodeRealm (Similar to https://docs.google.com/document/d/12_CkX6KbM9kt_lj1pdEgLB8-HQaozkJb7_nwQnHfTTg/edit#heading=h.drlp0amd3twr):
  • globalThis.process events like uncaughtException and unhandledRejection.
  • Should the built-in modules that can manipulate the process state and isolate state be exposed in the realm? e.g. node:v8 and process.exit.
• For each built-in modules that can be exposed in the NodeRealm:
  • Verify their binding data and handles/requests can be disposed once the realm is being disposed.
  • Run existing tests in the NodeRealm.

[mcollina]

Regarding process.exit(): it should "close" the Realm, similarly to how it works in worker_threads

[SimenB]

This is sorta #28823 and #31852, right?

[legendecas]

@SimenB This is sorta #28823 and #31852, right?

Effectively, yes.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Mark issue so that it is never considered stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.

[karankraina]

@mcollina @cjihrig @addaleax I tried to achieve something of this sort in my project and ended up creating a package.

Can you guys have a look and see if this is relevant to what we need here ?

https://github.com/karankraina/safer-vm/blob/main/src/context.ts

The idea is from node core only -

node/lib/repl.js

Line 204 in c7e4209

const globalBuiltins =

[mcollina]

@karankraina not really. You are exposing the parent native objects, while we are talking about exposing them natively in child. This would ensure safety.