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

@mcollina

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

@legendecas

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

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.

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

This is sorta #28823 and #31852, right?

@SimenB

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

Effectively, yes.

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.

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.

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Issues and PRs exempt from automated stale handling. 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.

@mcollina

@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 =

@karankraina

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

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

cjihrig commented on Feb 8, 2023

legendecas commented on Feb 9, 2023

mcollina commented on Feb 9, 2023

SimenB commented on Feb 14, 2023

legendecas commented on Feb 14, 2023

github-actions commented on Aug 14, 2023

github-actions commented on Feb 13, 2024

github-actions commented on Aug 12, 2024

karankraina commented on Oct 12, 2024

mcollina commented on Oct 15, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions