Why can Module.prototype.require be deleted?

[Melab]

Version

v18.0.0-pre

Platform

No response

Subsystem

No response

What steps will reproduce the bug?

delete require("module").prototype.require

How often does it reproduce? Is there a required condition?

No.

What is the expected behavior?

"Monkey patching" Node's internals is supposed to be impossible.

What do you see instead?

No response

Additional information

Per issue #30697, Node's internals were refactored to make them immune to modification by non-builtin code. So I am wondering why is it that Module.prototype is exposed to external code that can kill Node's module loading mechanism by deleting the property require on it?

[Trott]

#30697 is being discussed. It is an open question as to whether and how far Node.js should go to prevent tampering with prototypes in core side effects in core of tampering with prototypes.

[Melab]

#30697 is being discussed. It is an open question as to whether and how far Node.js should go to prevent tampering with prototypes in core.

My impression was that the ECMA-262 API components were the only things that needed to be in primordials to insulate Node built-in modules from the effects of mutated intrinsics. It was also either that require used by built-in modules was supposed to be different from the one passed to "userland" code or that each module received could break its own require but not the other modules' requires. And, the return value of require("module") would contain code for custom module loaders and not code used internally.

Is the mutability of Module.prototype the way by which alternative CommonJS module loaders for Node function? If so, how would alternative loaders work if Module.prototype were protected?

[Trott]

@nodejs/modules

[ljharb]

The primordials discussion is about language builtins; there is currently no plan or discussion or expectation I'm aware of about mutation of node's builtins themselves being supported - there's plenty of use cases that require node's builtins to be mutable, like monitoring systems.

In general, don't mutate things you don't own; the goal of primordials is that mutating something unrelated to a node builtin should not break that builtin. If you mutate any arbitrary thing you don't own, you should always expect that thing to break.

[Melab]

The primordials discussion is about language builtins; there is currently no plan or discussion or expectation I'm aware of about mutation of node's builtins themselves being supported - there's plenty of use cases that require node's builtins to be mutable, like monitoring systems.

In general, don't mutate things you don't own; the goal of primordials is that mutating something unrelated to a node builtin should not break that builtin. If you mutate any arbitrary thing you don't own, you should always expect that thing to break.

Can I get an answer to the question in my second paragraph?

[ljharb]

I assume that many use cases would break if it were locked down, yes - there’s a reason language and web builtins are mutable by default too.

[benjamingr]

Is the mutability of Module.prototype the way by which alternative CommonJS module loaders for Node function? If so, how would alternative loaders work if Module.prototype were protected?

Mostly yes, though some use require.extensions or other mechanisms and/or internals to do this. If module internals were protected (which no one is suggesting at this point) Node would provide an alternative API.