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 https://github.com/nodejs/node/pull/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 https://github.com/nodejs/node/issues/28823 and https://github.com/nodejs/node/issues/31852, right?

Effectively, yes.

[github-actions[bot]]

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[bot]]

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[bot]]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the https://github.com/nodejs/node/labels/never-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 - https://github.com/nodejs/node/blob/c7e42092f34f019fa0c4d9a2d0d49719af2f5daa/lib/repl.js#L204

[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.